Why chain of snapshots is used in ReorderBufferCommit?
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t38299psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 09:03 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t38299_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t38299_1 && git checkout t38299_1Patchset v1 (message #1) is on t38299_1
Hello,
While prowling through snapbuild & reorderbuffer code, I wondered: why a queue
of snapshots is used for replaying each transaction instead of just picking up
snapshot from snapbuilder once when COMMIT record is read? I am not aware of any
DDL/DML mix which would make this invalid: e.g. we can't insert something into
table in xact T1, then alter a column in xact T2, and then insert something more
in T1. All ALTER TABLE forms which are currently interesting from the decoding
POV obtain ACCESS EXCLUSIVE lock, conflicting with any other manipulations on the
table:
https://www.postgresql.org/docs/devel/static/sql-altertable.html
To confirm this, I tried to use single snapshot (see attached patch) and make
check of test_decoding and src/test/recovery passed all the tests.
The only reason I can think of is the desire to allow replay of in-progress
transactions some day. However, presently we are far from there. Moreover, if we
pretend that the rule is to replay xact with exactly the same catalog snapshot
which was used during its execution (not including any later changes), then we
violate it anyway due to "choose the latest base_snapshot of all subxacts's as a
base_snapshot during replay" logic, which is somewhat weird. If xact doesn't
have base snapshot itself, but has two subxacts both having one, currently we
will use latest snapshot to start decoding of subxact which actually had earlier
snapshot. On the whole, what is the value of 'base_snapshot' concept, why first
snapshots aren't logged to the change queue as any subsequent ones?
--
Arseny Sher
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Hi,
On 2018-03-01 08:17:33 +0300, Arseny Sher wrote:
While prowling through snapbuild & reorderbuffer code, I wondered: why a queue
of snapshots is used for replaying each transaction instead of just picking up
snapshot from snapbuilder once when COMMIT record is read? I am not aware of any
DDL/DML mix which would make this invalid: e.g. we can't insert something into
table in xact T1, then alter a column in xact T2, and then insert something more
in T1. All ALTER TABLE forms which are currently interesting from the decoding
POV obtain ACCESS EXCLUSIVE lock, conflicting with any other manipulations on the
table:
https://www.postgresql.org/docs/devel/static/sql-altertable.html
I don't think that's right. For one there's plenty types of DDL where no
such locking exists, consider e.g. composite datums where additional
columns can be added even after such a type is already used by another
table. For another, T1 might need to see a DDL change to a table that
has been made by T2 after T1 started, which is not prohibited by locking
if T1 uses the table first after T2 commits.
- Andres
Andres Freund <andres@anarazel.de> writes:
I don't think that's right. For one there's plenty types of DDL where no
such locking exists, consider e.g. composite datums where additional
columns can be added even after such a type is already used by another
table.
Oh, indeed. Never mind the last paragraph.
--
Arseny Sher
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company