Re: test_decoding assertion failure for the loss of top-sub transaction relationship
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: "kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, "dilipbalaut@gmail.com" <dilipbalaut@gmail.com>, "osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2022-09-06T10:25:25Z
Lists: pgsql-hackers
On Tue, Sep 6, 2022 at 1:17 PM kuroda.hayato@fujitsu.com
<kuroda.hayato@fujitsu.com> wrote:
>
> Dear hackers,
>
> > I agreed both that DEBUG2 messages are still useful but we should not
> > change the condition for output. So I prefer the idea suggested by Amit.
>
> PSA newer patch, which contains the fix and test.
>
> > > I have not verified but I think we need to backpatch this till 14
> > > because prior to that in DecodeCommit, we use to set the top-level txn
> > > as having catalog changes based on the if there are invalidation
> > > messages in the commit record. So, in the current scenario shared by
> > > Osumi-San, before SnapBuildCommitTxn(), the top-level txn will be
> > > marked as having catalog changes.
> >
> > I and Osumi-san are now investigating that, so please wait further reports and
> > patches.
>
> We investigated it about older versions, and in some versions *another stack-trace* has been found.
>
>
> About PG10-13, indeed, the failure was not occurred.
> In these versions transactions are regarded as
> that have catalog changes when the commit record has XACT_XINFO_HAS_INVALS flag.
> This flag will be set if the transaction has invalidation messages.
>
> When sub transaction changes system catalogs and user commits,
> all invalidation messages allocated in sub transaction will be transferred to top transaction.
> Therefore both transactions will be marked as containing catalog changes.
>
>
> About PG14 and 15, however, another stack-trace has been found.
> While executing the same workload, we got followings at the same SQL statement;
>
Did you get this new assertion failure after you applied the patch for
the first failure? Because otherwise, how can you reach it with the
same test case?
About patch:
else if (sub_needs_timetravel)
{
- /* track toplevel txn as well, subxact alone isn't meaningful */
+ elog(DEBUG2, "forced transaction %u to do timetravel due to one of
its subtransaction",
+ xid);
+ needs_timetravel = true;
SnapBuildAddCommittedTxn(builder, xid);
Why did you remove the above comment? I think it still makes sense to retain it.
--
With Regards,
Amit Kapila.
Commits
-
Fix executing invalidation messages generated by subtransactions during decoding.
- 343afa967106 15.1 landed
- 4fbe6096b954 14.6 landed
- 38dbaaf27387 13.9 landed
- 02600886c8a8 12.13 landed
- 216af69aec0d 11.18 landed
-
Fix assertion failures while processing NEW_CID record in logical decoding.
- 64ff0fe4e8c4 15.1 landed
- a592ed923e67 14.6 landed
- 25f7be1ca236 13.9 landed
- 1bf4d92060ee 12.13 landed
- 5f7076cb609e 11.18 landed
- 10ed7b9e4b19 10.23 landed
- 16b1fe0037dc 16.0 landed