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

From: Arseny Sher <a(dot)sher(at)postgrespro(dot)ru>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, "Hsu\, John" <hsuchen(at)amazon(dot)com>, "pgsql-bugs\(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: ERROR: subtransaction logged without previous top-level txn record
Date: 2020-02-03 09:20:30
Message-ID: 8736bs81sx.fsf@ars-thinkpad
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs pgsql-hackers

Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> writes:

>> I don't see a bug here. At least in reproduced scenario I see false
>> alert, as explained above: transaction with skipped xl_xact_assignment
>> won't be streamed as it finishes before confirmed_flush_lsn.
> Does this guarantee come from the fact that we need to wait for such a
> transaction before reaching a consistent snapshot state? If not, can
> you explain a bit more what makes you say so?

Right, see FULL_SNAPSHOT -> SNAPBUILD_CONSISTENT transition -- it exists
exactly for this purpose: once we have good snapshot, we need to wait
for all running xacts to finish to see all xacts we are promising to
stream in full. This ensures <restart_lsn, confirmed_flush_lsn> pair is
good (reading WAL since the former is enough to see all xacts committing
after the latter in full) initially, and slot advancement arrangements
ensure it stays good forever (see

Well, almost. This is true as long initial snapshot construction process
goes the long way of building the snapshot by itself. If it happens to
pick up from disk ready snapshot pickled there by another decoding
session, it fast path'es to SNAPBUILD_CONSISTENT, which is technically a
bug as described in

In theory, this bug could indeed lead to 'subtransaction logged without
previous top-level txn record' error. In practice, I think its
possibility is disappearingly small -- process of slot creation must be
intervened in a very short gap by another decoder who serializes its
snapshot (see the exact sequence of steps in the mail above). What is
much more probable (doesn't involve new slot creation and relatively
easily reproducible without sleeps) is false alert triggered by unlucky
position of restart_lsn.

Surely we still must fix it. I just mean
- People definitely encountered false alert, not this bug
(at least because nobody said this was immediately after slot
- I've no bright ideas how to relax the check to make it proper
without additional complications and I'm pretty sure this is
impossible (again, see above for details), so I'd remove it.

Arseny Sher
Postgres Professional:
The Russian Postgres Company

In response to


Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2020-02-03 10:38:10 BUG #16240: The now() function is populating different date time than expected
Previous Message Andres Freund 2020-02-03 09:15:46 Re: BUG #16223: Performance regression between 11.6 and 12.1 in an SQL query with a recursive CTE based on function

Browse pgsql-hackers by date

  From Date Subject
Next Message Kasahara Tatsuhito 2020-02-03 09:20:49 Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read)
Previous Message Fujii Masao 2020-02-03 08:32:59 Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read)