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 F3DEA948-1614-417F-B5F4-227152657AAA@amazon.com
Whole thread Raw
In response to Re: Avoiding data loss with synchronous replication  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On 7/23/21, 3:58 AM, "Amit Kapila" <amit.kapila16@gmail.com> wrote:
> On Fri, Jul 23, 2021 at 2:48 AM Bossart, Nathan <bossartn@amazon.com> wrote:
>> Instead of blocking query cancellations and backend terminations, I
>> think we should allow them to proceed, but we should keep the
>> transactions marked in-progress so they do not yet become visible to
>> sessions on the primary.
>>
>
> One naive question, what if the primary gets some error while changing
> the status from in-progress to committed? Won't in such a case the
> transaction will be visible on standby but not on the primary?

Yes.  In this case, the transaction would remain in-progress on the
primary until it can be marked committed.

>>  Once replication has caught up to the
>> the necessary point, the transactions can be marked completed, and
>> they would finally become visible.
>>
>
> If the session issued the commit is terminated, will this work be done
> by some background process?

I think the way I'm imagining it is that a background process would be
responsible for handling all of the "offloaded" transactions.  I'm not
wedded to any particular design at this point, though.

Nathan


pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)
Next
From: "Bossart, Nathan"
Date:
Subject: Re: Avoiding data loss with synchronous replication