Re: Disallow cancellation of waiting for synchronous replication
От | Marco Slot |
---|---|
Тема | Re: Disallow cancellation of waiting for synchronous replication |
Дата | |
Msg-id | CANNhMLBLsCS3gFwzABeZDu-m=RJK6MHPOUawOr8kO1vtWGhU2Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Disallow cancellation of waiting for synchronous replication (Andrey Borodin <x4mmm@yandex-team.ru>) |
Ответы |
Re: Disallow cancellation of waiting for synchronous replication
Re: Disallow cancellation of waiting for synchronous replication Re: Disallow cancellation of waiting for synchronous replication |
Список | pgsql-hackers |
On Fri, Dec 20, 2019 at 11:07 AM Andrey Borodin <x4mmm@yandex-team.ru> wrote: > I think changing synchronous_standby_names to some available standbys will resume all backends waiting for synchronousreplication. > 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
В списке pgsql-hackers по дате отправления: