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 CAA4eK1JHafK2wX=MB6F-AF2jA+2sHqG6+n4UtRmQ-MeUCngL=w@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  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
On Wed, Sep 30, 2020 at 2:46 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Wed, Sep 30, 2020 at 2:36 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > 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
>
> But once we prepare the transaction, we can not rollback individual
> subtransaction.
>

Sure but Rollback can come before prepare like in the case below which
will appear as concurrent abort (assume there is some DDL which
changes the table before the Rollback statement) because it has
already been done by the backend and that need to be caught by this
mechanism only.

Begin;
insert into t1 values(1,'aaa');
savepoint s1;
insert into t1 values(2,'aaa');
savepoint s2;
insert into t1 values(3,'aaa');
Rollback to savepoint s2;
insert into t1 values(4,'aaa');
Prepare Transaction 'foo';


-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Next
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions