Re: [HACKERS] logical decoding of two-phase transactions - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: [HACKERS] logical decoding of two-phase transactions
Date
Msg-id CAA4eK1+6wvs8zP-crCOXP2qn6jybqTXm9BH0F9V889sxoCL-Og@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] logical decoding of two-phase transactions  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: [HACKERS] logical decoding of two-phase transactions
List pgsql-hackers
On Tue, Sep 29, 2020 at 8:04 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> I have started looking into you latest patches,  as of now I have a
> few comments.
>
> v6-0001
>
> @@ -1987,7 +2072,7 @@ ReorderBufferProcessTXN(ReorderBuffer *rb,
> ReorderBufferTXN *txn,
>   prev_lsn = change->lsn;
>
>   /* Set the current xid to detect concurrent aborts. */
> - if (streaming)
> + if (streaming || rbtxn_prepared(change->txn))
>   {
>   curtxn = change->txn;
>   SetupCheckXidLive(curtxn->xid);
> @@ -2249,7 +2334,6 @@ ReorderBufferProcessTXN(ReorderBuffer *rb,
> ReorderBufferTXN *txn,
>   break;
>   }
>   }
> -
>
> For streaming transaction we need to check the xid everytime because
> there could concurrent a subtransaction abort, but
> for two-phase we don't need to call SetupCheckXidLive everytime,
> because we are sure that transaction is going to be
> the same throughout the processing.
>

While decoding transactions at 'prepare' time there could be multiple
sub-transactions like in the case below. Won't that be impacted if we
follow your suggestion here?

postgres=# Begin;
BEGIN
postgres=*# insert into t1 values(1,'aaa');
INSERT 0 1
postgres=*# savepoint s1;
SAVEPOINT
postgres=*# insert into t1 values(2,'aaa');
INSERT 0 1
postgres=*# savepoint s2;
SAVEPOINT
postgres=*# insert into t1 values(3,'aaa');
INSERT 0 1
postgres=*# Prepare Transaction 'foo';
PREPARE TRANSACTION

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: "Andrey V. Lepikhov"
Date:
Subject: Re: Adding Support for Copy callback functionality on COPY TO api
Next
From: Michael Paquier
Date:
Subject: Re: [DOC] Document concurrent index builds waiting on each other