From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Avoiding data loss with synchronous replication |
Date: | 2021-07-23 17:54:20 |
Message-ID: | C9E624CF-4928-432C-9561-376586F6F3F1@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7/23/21, 4:33 AM, "Andrey Borodin" <x4mmm(at)yandex-team(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bryn Llewellyn | 2021-07-23 17:55:11 | Re: Have I found an interval arithmetic bug? |
Previous Message | Bossart, Nathan | 2021-07-23 17:53:47 | Re: Avoiding data loss with synchronous replication |