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

From: Ajin Cherian <itsajin(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] logical decoding of two-phase transactions
Date: 2020-12-23 09:38:38
Message-ID: CAFPTHDZMJC1-cNFk32xoVYGq15hp+cF4=MMfuwxRt7N2eSoJSA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 22, 2020 at 8:59 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Tue, Dec 22, 2020 at 2:51 PM Ajin Cherian <itsajin(at)gmail(dot)com> wrote:
> >
> > On Sat, Dec 19, 2020 at 2:13 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > > Okay, I have changed the rollback_prepare API as discussed above and
> > > accordingly handle the case where rollback is received without prepare
> > > in apply_handle_rollback_prepared.
> >
> >
> > I have reviewed and tested your new patchset, I agree with all the
> > changes that you have made and have tested quite a few scenarios and
> > they seem to be working as expected.
> > No major comments but some minor observations:
> >
> > Patch 1:
> > logical.c: 984
> > Comment should be "rollback prepared" rather than "abort prepared".
> >
>
> Agreed.

Changed.

>
> > Patch 2:
> > decode.c: 737: The comments in the header of DecodePrepare seem out of
> > place, I think here it should describe what the function does rather
> > than what it does not.
> >
>
> Hmm, I have written it because it is important to explain the theory
> of concurrent aborts as that is not quite obvious. Also, the
> functionality is quite similar to DecodeCommit and the comments inside
> the function explain clearly if there is any difference so not sure
> what additional we can write, do you have any suggestions?

I have slightly re-worded it. Have a look.

>
> > reorderbuffer.c: 2422: It looks like pg_indent has mangled the
> > comments, the numbering is no longer aligned.
> >
>
> Yeah, I had also noticed that but not sure if there is a better
> alternative because we don't want to change it after each pgindent
> run. We might want to use (a), (b) .. notation instead but otherwise,
> there is no big problem with how it is.

Leaving this as is.

>
> > Patch 5:
> > worker.c: 753: Type: change "dont" to "don't"
> >
>
> Okay.

Changed.

>
> > Patch 6: logicaldecoding.sgml
> > logicaldecoding example is no longer correct. This was true prior to
> > the changes done to replay prepared transactions after a restart. Now
> > the whole transaction will get decoded again after the commit
> > prepared.
> >
> > postgres=# COMMIT PREPARED 'test_prepared1';
> > COMMIT PREPARED
> > postgres=# select * from
> > pg_logical_slot_get_changes('regression_slot', NULL, NULL,
> > 'two-phase-commit', '1');
> > lsn | xid | data
> > -----------+-----+--------------------------------------------
> > 0/168A060 | 529 | COMMIT PREPARED 'test_prepared1', txid 529
> > (1 row)
> >
>
> Agreed.

Changed.

>
> > Patch 8:
> > worker.c: 2798 :
> > worker.c: 3445 : disabling two-phase in tablesync worker.
> > considering new design of multiple commits in tablesync, do we need
> > to disable two-phase in tablesync?
> >
>
> No, but let Peter's patch get committed then we can change it.

OK, leaving it.

> Can you please update the patch for the points we agreed upon?

Changed and attached.
regards,
Ajin Cherian
Fujitsu Australia

Attachment Content-Type Size
v34-0002-Allow-decoding-at-prepare-time-in-ReorderBuffer.patch application/octet-stream 68.4 KB
v34-0003-Refactor-spool-file-logic-in-worker.c.patch application/octet-stream 3.6 KB
v34-0005-Add-support-for-apply-at-prepare-time-to-built-i.patch application/octet-stream 38.9 KB
v34-0004-Track-replication-origin-progress-for-rollbacks.patch application/octet-stream 3.9 KB
v34-0001-Extend-the-output-plugin-API-to-allow-decoding-o.patch application/octet-stream 41.6 KB
v34-0006-Support-2PC-documentation.patch application/octet-stream 5.8 KB
v34-0007-Support-2PC-txn-subscriber-tests.patch application/octet-stream 60.4 KB
v34-0008-Support-2PC-txn-Subscription-option.patch application/octet-stream 34.8 KB
v34-0009-Support-2PC-consistent-snapshot-isolation-tests.patch application/octet-stream 5.2 KB
v34-0010-Support-2PC-txn-tests-for-concurrent-aborts.patch application/octet-stream 16.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2020-12-23 09:38:51 Re: Single transaction in the tablesync worker?
Previous Message Hou, Zhijie 2020-12-23 09:35:25 RE: Parallel copy