Om uw vraag direct te beantwoorden, waarom minimaal en waarom niet maximaal? Omdat de nieuwe WAL-segmenten sneller kunnen groeien dan de RemoveOldXlogFiles(_logSegNo, recptr) functie kan de oude verwijderen.
Ook is de formule voor het berekenen van het waarschijnlijke aantal WAL-segmenten in de documenten onjuist. Ik heb altijd een paar WAL's meer dan checkpoint_segments + wal_keep_segments + 1 Een veel nauwkeurigere formule is deze:wal_keep_segments + 2 * checkpoint_segments + 1
Er is hier een oud, maar echt goed bericht over:http://www.postgresql.org/message-id/[email protected]
Als u massieve inserts doet, zullen uw WAL-segmenten sneller groeien dan ze kunnen worden verwijderd. Dit heeft me deze week opgeleverd. Ik verwachtte dat de pg_xlog een relatief constante grootte zou behouden. Er werd 's nachts een groot proces uitgevoerd en toen ik de volgende ochtend aan het werk ging, crashte mijn postgres-instantie omdat het volume dat ik aankoppelde om die WAL's op te ploffen helemaal vol was. Postgres vulde het boek, probeerde nog meer WAL's te schrijven, maar dat lukte niet, en stierf abrupt. Gelukkig draaien we replica's achter pgpool2.
Als je een nieuwsgierige geest hebt, raad ik je aan om door de broncode van postgres te bladeren. Het is gigantisch en in C, maar de code-opmerkingen helpen echt. Dit bestand in het bijzonder is verhelderend omdat het dieper ingaat op hoe checkpointing werkt en hoe het verwijderen van oude WAL-segmenten gebeurt:https://github.com/postgres/postgres/blob/master/src/backend/access/transam/xlog.c