Để trả lời trực tiếp câu hỏi của bạn, tại sao tối thiểu và tại sao không tối đa? Vì các phân đoạn WAL mới có thể phát triển nhanh hơn RemoveOldXlogFiles(_logSegNo, recptr) chức năng có thể xóa những cái cũ.
Ngoài ra, công thức tính số phân đoạn WAL có thể xảy ra trong tài liệu là sai. Tôi luôn có thêm một vài WAL ngoài checkpoint_segments + wal_keep_segments + 1 Một công thức chính xác hơn nhiều là sau:wal_keep_segments + 2 * checkpoint_segments + 1
Có một bài đăng cũ, nhưng rất hay về điều này ở đây: http://www.postgresql.org/message-id/[email protected]
Nếu bạn thực hiện nhiều lần chèn, các phân đoạn WAL của bạn sẽ phát triển nhanh hơn mức chúng có thể bị xóa. Điều này đã làm cho tôi chỉ trong tuần này. Tôi mong đợi pg_xlog duy trì kích thước tương đối ổn định. Có một quá trình lớn được chạy vào ban đêm và khi tôi đi làm vào sáng hôm sau, phiên bản postgres của tôi đã bị lỗi vì khối lượng tôi gắn để mở các WAL đó đã hoàn toàn đầy. Postgres đã lấp đầy tập, cố gắng viết nhiều WAL hơn nữa, nhưng không thể, và đột ngột qua đời. May mắn thay, chúng tôi chạy các bản sao đằng sau pgpool2.
Nếu bạn có óc tò mò, tôi khuyến khích bạn duyệt qua mã nguồn postgres. Nó khổng lồ và bằng C, nhưng các bình luận mã thực sự hữu ích. Tệp này đặc biệt thú vị khi nó đi sâu vào các sơ đồ về cách hoạt động của điểm kiểm tra và cách loại bỏ các phân đoạn WAL cũ xảy ra: https://github.com/postgres/postgres/blob/master/src/backend/access/transam/xlog.c
