Horton

Re: [HACKERS] logical decoding of two-phase transactions

Dilip Kumar <dilipbalaut@gmail.com>

View thread View on postgr.es
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Ajin Cherian <itsajin@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Masahiko Sawada <sawada.mshk@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-09-30T10:00:06Z
Lists: pgsql-hackers 
On Wed, Sep 30, 2020 at 3:27 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Sep 30, 2020 at 3:12 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > On Wed, Sep 30, 2020 at 3:08 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > 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';
> >
> >
> > If we are streaming on the prepare that means we must have decoded
> > that rollback WAL which means we should have removed the
> > ReorderBufferTXN for those subxact.
> >
>
> Okay, valid point. We can avoid setting it for each sub-transaction in
> that case but OTOH even if we allow to set it there shouldn't be any
> bug.

Right, there will not be any bug, just an optimization.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

Commits

  1. Add prepare API support for streaming transactions in logical replication.

  2. Doc: minor improvements for logical replication protocol documentation.

  3. Fix test failure in 021_twophase.pl.

  4. Refactor to make common functions in proto.c and worker.c.

  5. Unify PostgresNode's new() and get_new_node() methods

  6. Fix potential buffer overruns in proto.c.

  7. Add support for prepared transactions to built-in logical replication.

  8. Refactor function parse_subscription_options.

  9. Allow enabling two-phase option via replication protocol.

  10. Don't use Asserts to check for violations of replication protocol.

  11. Improve psql tab completion for options of subcriptions and publications

  12. Rearrange logrep worker's snapshot handling some more.

  13. doc: Update information of new messages for logical replication.

  14. ALTER SUBSCRIPTION ... ADD/DROP PUBLICATION

  15. Allow pgoutput to send logical decoding messages.

  16. Refactor function parse_output_parameters.

  17. Avoid repeated decoding of prepared transactions after a restart.

  18. Fix an oversight in ReorderBufferFinishPrepared.

  19. Allow multiple xacts during table sync in logical replication.

  20. Fix replication of in-progress transactions in tablesync worker.

  21. Fix 'skip-empty-xacts' option in test_decoding for streaming mode.

  22. Use Enum for top level logical replication message types.

  23. Add support for streaming to built-in logical replication.

  24. Fix the logical streaming test.

  25. Implement streaming mode in ReorderBuffer.

  26. Extend the logical decoding output plugin API with stream methods.

  27. Store 2PC GID in commit/abort WAL recs for logical decoding