Re: Avoiding data loss with synchronous replication

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

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

In response to

Responses

Browse pgsql-hackers by date

  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