Ilya Kosmodemiansky bàn về file cấu hình postgresql.conf "mặc định"

Đây là phần 1 trong loạt bốn bài dựa trên bài nói "The 'default' postgresql.conf, step by step" mà Ilya Kosmodemiansky trình bày tại PGConf.EU 2026 ở Valencia ngày 21/10/2026. Bản blog bổ sung những phần không có trong bài nói 45 phút, như kết quả kiểm thử và cơ chế đằng sau mỗi thiết lập.

Vì sao cần một bộ cấu hình nền

Một bản cài PostgreSQL mới khởi đầu với các giá trị mặc định thận trọng, được chọn để Postgres chạy được trên gần như mọi phần cứng, từ máy nhỏ đến máy ảo yếu, chứ không tối ưu cho server thực tế. Các mặc định có cải thiện qua từng phiên bản nhưng vẫn cần đọc tài liệu kỹ để biết nên đổi gì. Server thật có nhiều RAM hơn, đĩa nhanh hơn, mạng không ổn định, có connection pooler và ứng dụng để giao dịch mở.

Tại Data Egret, khi lập cluster mới hoặc tiếp quản cluster có sẵn, nhóm gần như luôn áp dụng cùng một bộ thay đổi, gọi là "default postgresql.conf" của họ. Đây không phải hướng dẫn tinh chỉnh cho một workload cụ thể mà là nền tảng an toàn cho hầu hết server production, dựa trên khả năng phần cứng và các vấn đề thường gặp của workload OLTP điển hình. Từ đó mới điều chỉnh, kiểm thử và cải thiện tiếp.

Mọi giá trị mặc định trong loạt bài là của PostgreSQL 18, kết quả lấy từ PostgreSQL 18.6 đóng gói bởi Debian. Loạt bài chia làm bốn phần: phần 1 về cơ chế cấu hình và thiết lập kết nối; phần 2 về bộ nhớ, WAL và checkpoint; phần 3 về autovacuum và freezing; phần 4 về logging, thống kê, replication và những thay đổi từ PostgreSQL 14.

399 thiết lập, chỉ vài cái thực sự quan trọng

PostgreSQL 18 có 399 thiết lập, tăng dần qua các phiên bản: cluster mới từ gói Debian có 271 ở bản 10, 348 ở bản 14 và 399 ở bản 18. Không ai cần chạm vào cả 399 thiết lập; bộ nền của nhóm chỉ thay đổi hoặc kiểm tra khoảng 60 cái, phần còn lại giữ mặc định hoặc chỉ quan trọng với cấu hình đặc biệt.

postgresql.conf và postgresql.auto.conf

PostgreSQL đọc thiết lập từ hai file. postgresql.conf là file chính, sửa bằng tay; trên Debian/Ubuntu nó nằm ở /etc/postgresql/<version>/<cluster>/, trên hầu hết hệ thống khác nằm trong thư mục dữ liệu. postgresql.auto.conf nằm trong thư mục dữ liệu và do PostgreSQL tự ghi: ALTER SYSTEM SET đưa giá trị vào file này, ALTER SYSTEM RESET xóa đi; các công cụ như pg_basebackup -R cũng ghi vào đây. Không nên sửa tay file này khi server đang chạy.

PostgreSQL đọc postgresql.auto.conf sau postgresql.conf, và trong mỗi file thì lần xuất hiện cuối cùng của một thiết lập sẽ thắng. Vì vậy giá trị đặt bằng ALTER SYSTEM thắng postgresql.conf. Đây là nguồn nhầm lẫn kinh điển: ai đó sửa postgresql.conf, reload mà không thấy gì thay đổi, vì từ lâu người khác đã chạy ALTER SYSTEM cho cùng thiết lập đó.

Nếu cấu hình được quản lý bằng công cụ như Ansible hay Patroni, có thể không muốn ai ghi vào postgresql.auto.conf. Từ PostgreSQL 17, allow_alter_system = off khiến ALTER SYSTEM báo lỗi. Tài liệu nói rõ đây không phải tính năng bảo mật: superuser vẫn đổi cấu hình bằng cách khác được.

Các cách đổi thiết lập khác

Ngoài file, còn hai cách đổi thiết lập, đều dễ gây nhầm lẫn. Thứ nhất là dòng lệnh server: thiết lập truyền cho tiến trình postgres lúc khởi động bằng -c name=value (qua pg_ctl -o hoặc systemd unit) đè lên cả hai file, kể cả ALTER SYSTEM, và chỉ mất khi khởi động lại server mà không kèm chúng; reload không thay đổi chúng. Debian dùng cách này để truyền config_file. Thứ hai là đặt ở mức database, role hay session bằng ALTER DATABASE … SET, ALTER ROLE … SET hoặc SET; thiết lập nào cho phép điều này phụ thuộc vào context của nó.

postgresql.conf cũng hỗ trợ include: include 'file' đọc file khác như thể viết tại chỗ và báo lỗi nếu thiếu; include_if_exists chỉ ghi log khi thiếu; include_dir đọc mọi file .conf trong thư mục theo thứ tự tên file. File postgresql.conf của Debian kết thúc bằng include_dir = 'conf.d', là chỗ tốt để đặt thiết lập riêng. Khi sửa tay, nhóm giữ nguyên vị trí các giá trị, không sắp xếp lại file, để người quen file gốc vẫn tìm thấy thiết lập ở chỗ cũ và diff vẫn dễ đọc.

Dấu nháy đơn, và vì sao reload an toàn hơn restart

Giá trị không phải số hay từ đơn giản phải đặt trong nháy đơn, ví dụ work_mem = '128MB'; dùng nháy kép là lỗi cú pháp. Hậu quả phụ thuộc vào reload hay restart. Nếu thêm work_mem = "128MB" vào cuối file rồi xem pg_file_settings, view này hiện lỗi cú pháp trước khi bất cứ điều gì được áp dụng. Reload với file lỗi là vô hại: server ghi log lỗi, tiếp tục chạy và không áp dụng gì. Restart với cùng file thì không vô hại: server dừng và không khởi động lại được. Vì vậy nên tạo thói quen: sau khi sửa file, kiểm tra lỗi trong pg_file_settings, rồi reload, chỉ restart khi thiết lập thực sự cần.

pg_settings: nguồn sự thật tốt nhất

Dù giá trị đến từ đâu, view pg_settings cho thấy kết quả: mỗi thiết lập một dòng với giá trị đang có hiệu lực và nguồn gốc. Các cột quan trọng nhất khi làm việc hằng ngày:

• setting và unit: giá trị luôn hiện theo đơn vị gốc, ví dụ 3600 giây thay vì 60min; shared_buffers tính theo trang 8 kB nên 16384 nghĩa là 128 MB.
• boot_val: mặc định biên dịch sẵn; so setting với boot_val để thấy ngay điều gì đã bị đổi.
• source, sourcefile, sourceline: nguồn của giá trị, tới tận file và dòng, trả lời nhanh câu hỏi "vì sao giá trị không như tôi viết". Chỉ superuser và role có quyền của pg_read_all_settings mới thấy file và dòng.
• context: thay đổi cần gì để có hiệu lực.
• pending_restart: bằng t nếu file có giá trị mới mà server chưa áp dụng vì cần restart.

Sau ALTER SYSTEM SET work_mem = '64MB' và reload, cả pg_file_settings lẫn pg_settings đều chỉ về postgresql.auto.conf. Nếu còn nghi ngờ, hãy kiểm tra pg_settings: đây là nơi duy nhất nói đúng sự thật về server đang chạy.

Category và context

Mỗi thiết lập thuộc một category, theo cùng cấu trúc với postgresql.conf và chương tài liệu về cấu hình server. PostgreSQL 18 có 46 category (bản 10 có 38), như "Connections and Authentication / Connection Settings", "Resource Usage / Memory", "Write-Ahead Log / Checkpoints" hay "Vacuuming / Automatic Vacuuming". Thiết lập của extension được nạp, ví dụ pg_stat_statements.max, nằm ở category riêng "Customized Options". Category hữu ích khi tìm hiểu một vùng chưa quen.

Cột context là thứ người mới hay bỏ qua nhất, trả lời câu hỏi thực tế nhất: phải làm gì để thay đổi có hiệu lực. Có bảy context, trên bản 18.6 phân bố như sau: user 151, sighup 104, postmaster 69, superuser 49, internal 20, superuser-backend 4, backend 2.

Nguồn: Planet PostgreSQL