Horton

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

Ajin Cherian <itsajin@gmail.com>

View thread View on postgr.es
From: Ajin Cherian <itsajin@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Peter Smith <smithpb2250@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-11-04T10:15:59Z
Lists: pgsql-hackers 
On Wed, Nov 4, 2020 at 9:02 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Nov 4, 2020 at 3:01 PM Ajin Cherian <itsajin@gmail.com> wrote:
> >
> > On Mon, Nov 2, 2020 at 9:40 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > On Wed, Oct 28, 2020 at 10:50 AM Peter Smith <smithpb2250@gmail.com> wrote:
> > > 2.
> > > +DecodePrepare(LogicalDecodingContext *ctx, XLogRecordBuffer *buf,
> > > +   xl_xact_parsed_prepare * parsed)
> > > +{
> > > ..
> > > + if (SnapBuildXactNeedsSkip(ctx->snapshot_builder, buf->origptr) ||
> > > + (parsed->dbId != InvalidOid && parsed->dbId != ctx->slot->data.database) ||
> > > + ctx->fast_forward || FilterByOrigin(ctx, origin_id))
> > > + return;
> > > +
> > >
> > > I think this check is the same as the check in DecodeCommit, so you
> > > can write some comments to indicate the same and also why we don't
> > > need to call ReorderBufferForget here. One more thing is to note is
> > > even if we don't need to call ReorderBufferForget here but still we
> > > need to execute invalidations (which are present in top-level txn) for
> > > the reasons mentioned in ReorderBufferForget. Also, if we do this,
> > > don't forget to update the comment atop
> > > ReorderBufferImmediateInvalidation.
> >
> > I have updated the comments. I wasn't sure of when to execute
> > invalidations. Should I only
> > execute invalidations if this was for another database than what was
> > being decoded or should
> > I execute invalidation every time we skip?
> >
>
> I think so. Did there exist any such special condition in DecodeCommit
> or do you have any other reason in your mind for not doing it every
> time we skip? We probably might not need to execute when the database
> is different (at least I can't think of a reason for the same) but I
> guess this doesn't make much difference and it will keep the code
> consistent with what we do in DecodeCommit.
>

I was just basing it on the comments in the DecodeCommit:


     * We can't just use ReorderBufferAbort() here, because we need to execute
     * the transaction's invalidations.  This currently won't be needed if
     * we're just skipping over the transaction because currently we only do
     * so during startup, to get to the first transaction the client needs. As
     * we have reset the catalog caches before starting to read WAL, and we
     * haven't yet touched any catalogs, there can't be anything to invalidate.
     * But if we're "forgetting" this commit because it's it happened in
     * another database, the invalidations might be important, because they
     * could be for shared catalogs and we might have loaded data into the
     * relevant syscaches.

regards,
Ajin Cherian
Fujitsu Australia

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