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.
Hm, after thinking for a while, I tend to agree with the above approach - meaning, query cancel interrupt processing can completely be disabled in SyncRepWaitForLSN() and process proc die interrupt immediately, this approach requires no GUC as opposed to the proposed v1 patch upthread. However, it's good to see what other hackers think about this. > When the network is partitioned and somewhere standby is promoted you > definitely want infinite wait for cancels. Yet once upon a time you want to > shutdown postgres without coredump - thus proc die needs to be processed. Agree. On Mon, May 9, 2022 at 4:39 PM Andrey Borodin <x4...@yandex-team.ru> wrote: > > > On 26 Apr 2022, at 11:26, Laurenz Albe <laurenz.a...@cybertec.at> wrote: > > > > Is it worth adding additional complexity that is not a complete solution? > > Its not additional complexity. It is removing additional complexity that made > sync rep interruptible. (But I'm surely talking not about GUCs like > synchronous_replication_naptime_before_cancel - wait of sync rep must be > indefinite until synchrous_commit\synchronous_standby_names are satisfied ) > > And yes, we need additional complexity - but in some other place. Transaction > can also be locally committed in presence of a server crash. But this another > difficult problem. Crashed server must not allow data queries until LSN of > timeline end is successfully replicated to synchronous_standby_names. Hm, that needs to be done anyways. How about doing as proposed initially upthread [1]? Also, quoting the idea here [2]. Thoughts? [1] https://www.postgresql.org/message-id/CALj2ACUrOB59QaE6=jf2cfayv1mr7fzd8tr4ym5+oweyg1s...@mail.gmail.com [2] 2) Wait for sync standbys to catch up upon restart after the crash or in the next txn after the old locally committed txn was canceled. One way to achieve this is to let the backend, that's making the first connection, wait for sync standbys to catch up in ClientAuthentication right after successful authentication. However, I'm not sure this is the best way to do it at this point. Regards, Bharath Rupireddy.
