From: | Hannu Krosing <hannuk(at)google(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Cc: | Noah Misch <nmisch(at)google(dot)com> |
Subject: | Why are wal_keep_size, max_slot_wal_keep_size requiring server restart? |
Date: | 2023-12-09 11:32:22 |
Message-ID: | CAMT0RQSRTArk=YLVjzQC7S1WG9R3iFyYtJ+Z6MYQHtCMR3NVAg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello fellow Hackers,
Does anyone know why we have decided that the wal_keep_size,
max_slot_wal_keep_size GUCs "can only be set in the postgresql.conf
file or on the server command line." [1]?
It does not seem fundamentally needed , as they are "kind of
guidance", especially the second one.
The first one - wal_keep_size - could be something that is directly
relied on in some code paths, so setting it in a live database could
involve some two-step process, where you first set the value and then
wait all current transactions to finish before you do any operations
depending on the new value, like removing the wal files no more kept
because of earlier larger value. moving it up should need no extra
action. Moving it up then down immediately after could cause some
interesting race conditions when you move it down lower than it was in
the beginning, so "wait for all transactions to finish" should apply
in all cases
For the second one - max_slot_wal_keep_size - I can not immediately
come up with a scenario where just setting it could cause any
unexpected consequences. If you set it to a value below a current slot
value you *do* expect the slot to be invalidated. if you set it to a
larger than current value, then infringing slots get more time to
correct themselves. Both behaviours would be much more useful if you
did not have to restart the whole server to make adjustments.
-
[1] https://www.postgresql.org/docs/current/runtime-config-replication.html#GUC-WAL-KEEP-SIZE
Best Regards
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2023-12-09 11:38:46 | Re: Make COPY format extendable: Extract COPY TO format implementations |
Previous Message | Heikki Linnakangas | 2023-12-09 09:23:00 | Re: Streaming I/O, vectored I/O (WIP) |