Re: ERROR: subtransaction logged without previous top-level txn record - Mailing list pgsql-bugs

On Tue, Feb 11, 2020 at 5:36 PM Arseny Sher <a.sher@postgrespro.ru> wrote:
>
>
> 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.
>
There is one more inconsistency in the test case which I faced while
trying to reproduce.  The problem is that, after "s0_begin"
"s0_first_subxact", steps the open transaction is the top-transaction
because we have generated the sub-transaction and closed it.  Now,
during the "s0_many_subxacts" step, while scanning the system table
(e.g. for finding the function) the top-transaction might log the WAL
for the hint bits.  And then we will lose the purpose of the test
because we will get the WAL for the top-transaction, after the restart
point and then there will be no error.  For fixing this I have
modified the "s0_first_subxact" as shown below

+step "s0_first_subxact" {
+    DO LANGUAGE plpgsql $$
+      BEGIN
+        BEGIN
+          INSERT INTO harvest VALUES (41);
+ EXCEPTION WHEN OTHERS THEN RAISE;
+ END;
+      END $$;
+}
savepoint s1;   -- added extra
INSERT INTO harvest VALUES (41);  --added extra

Basically, after these two steps, the open transaction will be the
sub-transaction, not the top-transaction and that will make sure that
even if the future steps log some WAL then those will be under the
sub-transaction, not the top-transaction.

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