Re: Disallow cancellation of waiting for synchronous replication

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Marco Slot <marco(at)citusdata(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, dim(at)tapoueh(dot)org
Subject: Re: Disallow cancellation of waiting for synchronous replication
Date: 2019-12-20 10:07:26
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> 20 дек. 2019 г., в 12:23, Marco Slot <marco(at)citusdata(dot)com> написал(а):
> On Fri, Dec 20, 2019 at 6:04 AM Andrey Borodin <x4mmm(at)yandex-team(dot)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.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Jehan-Guillaume de Rorthais 2019-12-20 10:14:28 Re: Fetching timeline during recovery
Previous Message Jehan-Guillaume de Rorthais 2019-12-20 09:55:25 Re: How is this possible "publication does not exist"