On Tue, May 10, 2022 at 5:55 PM Andrey Borodin <x4...@yandex-team.ru> wrote: > > > 10 мая 2022 г., в 12:59, Bharath Rupireddy > > <bharath.rupireddyforpostg...@gmail.com> написал(а): > > > > If okay, I can make the GUC behave this way - value 0 existing > > behaviour i.e. no wait for sync repl ack, just process query cancels > > and proc die interrupts immediately; value -1 wait unboundedly for the > > ack; value > 0 wait for specified milliseconds for the ack. > +1 if we make -1 and 0 only valid values. > > > query cancels or proc die interrupts > > Please note, that typical HA tool would need to handle query cancels and proc > die interrupts differently.
Agree. > When the network is partitioned and somewhere standby is promoted you > definitely want infinite wait for cancels. When standby is promoted, no point the old primary waiting forever for ack assuming we are going to discard it. > Yet once upon a time you want to shutdown postgres without coredump - thus > proc die needs to be processed. I think users can still have the flexibility to set the right amounts of time to process cancel and proc die interrupts. IMHO, the GUC can still have 0, -1 and value > 0 in milliseconds, let the users decide on what they want. Do you see any problems with this? Thoughts? Regards, Bharath Rupireddy.
