From: | Marco Slot <marco(at)citusdata(dot)com> |
---|---|
To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
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-21 10:34:05 |
Message-ID: | CANNhMLBLsCS3gFwzABeZDu-m=RJK6MHPOUawOr8kO1vtWGhU2Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Dec 20, 2019 at 11:07 AM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
> 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?
The GUCs are not re-checked in the main loop in SyncRepWaitForLSN, so
backends will remain stuck there even if synchronous replication has
been (temporarily) disabled while they were waiting.
I do agree with the general sentiment that terminating the connection
is preferable over sending a response to the client (except when
synchronous replication was already disabled). Synchronous replication
does not guarantee that a committed write is actually on any replica,
but it does in general guarantee that a commit has been replicated
before sending a response to the client. That's arguably more
important because the rest of what the application might depend on the
transaction completing and replicating successfully. I don't know of
cases other than cancellation in which a response is sent to the
client without replication when synchronous replication is enabled.
The error level should be FATAL instead of PANIC, since PANIC restarts
the database and I don't think there is a reason to do that.
Marco
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2019-12-21 15:11:17 | Re: Disallow cancellation of waiting for synchronous replication |
Previous Message | Thomas Munro | 2019-12-21 08:01:58 | Re: Preserve versions of initdb-created collations in pg_upgrade |