Re: ERROR: subtransaction logged without previous top-level txn record

Arseny Sher <a.sher@postgrespro.ru>

From: Arseny Sher <a.sher@postgrespro.ru>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Arseny Sher <a.sher@postgrespro.ru>, Andres Freund <andres@anarazel.de>, "Hsu\, John" <hsuchen@amazon.com>, "pgsql-bugs\@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Date: 2020-02-11T12:06:02Z
Lists: pgsql-bugs, pgsql-hackers

Attachments

Amit Kapila <amit.kapila16@gmail.com> writes:

>> That's weird, it reliably fails with expected error for me. There are
>> already two s2_checkpoint's: first establishes potential (broken)
>> restart_lsn (serializes snapshot after first xl_xact_assignment of s0
>> xact, but before first record of s1 xact), the second ensures
>> s2_get_changes directly following it will actually advance the slot,
>>
>
> In my case, s2_get_changes doesn't seem to be advancing the restart
> lsn because when it processed running_xact by s2_checkpoint, the slots
> confirm flush location (slot->data.confirmed_flush) was behind it.  As
> confirmed_flush was behind running_xact of s2_checkpoint, it couldn't
> update slot->candidate_restart_lsn (in function
> LogicalIncreaseRestartDecodingForSlot).  I think the confirmed_flush
> location will only be updated at the end of get_changes.  This is the
> reason I need extra get_changes call to generate an error.
>
> I will think and investigate this more, but thought of sharing the
> current situation with you.  There is something different going on in
> my system or maybe the nature of test is like that.

Ah, I think I know what's happening -- you have one more
xl_running_xacts which catches the advancement -- similar issue is
explained in the comment in oldest_xmin.spec.

Try attached.

Commits

  1. Stop demanding that top xact must be seen before subxact in decoding.

  2. logical decoding: process ASSIGNMENT during snapshot build

  3. Fix operator naming in pg_trgm GUC option descriptions