> 20 дек. 2019 г., в 12:23, Marco Slot <ma...@citusdata.com> написал(а):
>
> On Fri, Dec 20, 2019 at 6:04 AM Andrey Borodin <x4...@yandex-team.ru> wrote:
>> I think proper solution here would be to add GUC to disallow cancellation of
>> synchronous replication. Retry step 3 will wait on locks after hanging 1 and
>> data will be consistent.
>> Three is still a problem when backend is not canceled, but terminated [2].
>> Ideal solution would be to keep locks on changed data. Some well known
>> databases threat termination of synchronous replication as system failure
>> and refuse to operate until standbys appear (see Maximum Protection mode).
>> From my point of view it's enough to PANIC once so that HA tool be informed
>> that something is going wrong.
>
> Sending a cancellation is currently the only way to resume after
> disabling synchronous replication. Some HA solutions (e.g.
> pg_auto_failover) rely on this behaviour. Would it be worth checking
> whether synchronous replication is still required?
I think changing synchronous_standby_names to some available standbys will
resume all backends waiting for synchronous replication.
Do we need to check necessity of synchronous replication in any other case?
Best regards, Andrey Borodin.
