From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, "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:53:47 |
Message-ID: | 71C2E458-7C7A-442A-B28A-EA37EC7F662D@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7/23/21, 4:23 AM, "Laurenz Albe" <laurenz(dot)albe(at)cybertec(dot)at> wrote:
> But that would mean that changes ostensibly rolled back (because the
> cancel request succeeded) will later turn out to be committed after all,
> just like it is now (only later). Where is the advantage?
The advantage is that I can cancel waits for synchronous replication
without risking data loss. The transactions would still be marked in-
progress until we get the proper acknowledgement from the standbys.
> Besides, there is no room for another transaction status in the
> commit log.
Right. Like the existing synchronous replication functionality, the
commit log would be updated, but the transactions would still appear
to be in-progress. Today, this is done via the procarray.
Nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Bossart, Nathan | 2021-07-23 17:54:20 | Re: Avoiding data loss with synchronous replication |
Previous Message | Bossart, Nathan | 2021-07-23 17:53:21 | Re: Avoiding data loss with synchronous replication |