Re: Avoiding data loss with synchronous replication - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: Avoiding data loss with synchronous replication
Date
Msg-id C9E624CF-4928-432C-9561-376586F6F3F1@amazon.com
Whole thread Raw
In response to Re: Avoiding data loss with synchronous replication  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: Avoiding data loss with synchronous replication  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-hackers
On 7/23/21, 4:33 AM, "Andrey Borodin" <x4mmm@yandex-team.ru> wrote:
> Thanks for you interest in the topic. I think in the thread [0] we almost agreed on general design.
> The only left question is that we want to threat pg_ctl stop and kill SIGTERM differently to pg_terminate_backend().

I didn't get the idea that there was a tremendous amount of support
for the approach to block canceling waits for synchronous replication.
FWIW this was my initial approach as well, but I've been trying to
think of alternatives.

If we can gather support for some variation of the block-cancels
approach, I think that would be preferred over my proposal from a
complexity standpoint.  Robert's idea to provide a way to understand
the intent of the cancellation/termination request [0] could improve
matters.  Perhaps adding an argument to pg_cancel/terminate_backend()
and using different signals to indicate that we want to cancel the
wait would be something that folks could get on board with.

Nathan

[0] https://www.postgresql.org/message-id/CA%2BTgmoaW8syC_wqQcsJ%3DsQ0gTbFVC6MqYmxbwNHk5w%3DxJ-McOQ%40mail.gmail.com


pgsql-hackers by date:

Previous
From: "Bossart, Nathan"
Date:
Subject: Re: Avoiding data loss with synchronous replication
Next
From: Bryn Llewellyn
Date:
Subject: Re: Have I found an interval arithmetic bug?