| 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: | Whole Thread | Raw Message | 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 |