För att svara direkt på din fråga, varför minimum och varför inte maximum? Eftersom de nya WAL-segmenten kan växa snabbare än RemoveOldXlogFiles(_logSegNo, recptr) funktionen kan ta bort de gamla.
Formeln för att beräkna det troliga antalet WAL-segment i dokumenten är också fel. Jag har alltid några fler WAL än checkpoint_segments + wal_keep_segments + 1 En mycket mer exakt formel är denna:wal_keep_segments + 2 * checkpoint_segments + 1
Det finns ett gammalt, men riktigt bra inlägg om detta här:http://www.postgresql.org/message-id/[email protected]
Om du gör massiva insatser kommer dina WAL-segment att växa snabbare än de kan tas bort. Det här fick mig bara den här veckan. Jag förväntade mig att pg_xlog skulle bibehålla en relativt konstant storlek. Det var en stor process som kördes på natten och när jag kom till jobbet följande morgon kraschade min postgres-instans eftersom volymen jag monterade för att ploppa dessa WALs på var helt full. Postgres fyllde volymen, försökte skriva ännu fler WALs, kunde inte och dog plötsligt. Som tur är kör vi repliker bakom pgpool2.
Om du är nyfiken rekommenderar jag att du bläddrar i postgres källkod. Det är jättelikt och i C, men kodkommentarerna hjälper verkligen. Särskilt den här filen är upplysande när den kommer in i muttrarna och bultarna för hur checkpointing fungerar och hur man tar bort gamla WAL-segment:https://github.com/postgres/postgres/blob/master/src/backend/access/transam/xlog.c