From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com> |
Subject: | Re: An attempt to avoid locally-committed-but-not-replicated-to-standby-transactions in synchronous replication |
Date: | 2022-05-10 12:25:01 |
Message-ID: | 11FF616C-C78C-41AA-A823-E3D4E745ACE5@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 10 мая 2022 г., в 12:59, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)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.
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.
Thanks!
Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | Bernd Helmle | 2022-05-10 12:29:31 | Re: Allowing REINDEX to have an optional name |
Previous Message | Ajin Cherian | 2022-05-10 11:33:49 | Re: Support logical replication of DDLs |