Why chain of snapshots is used in ReorderBufferCommit?
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
Attachments:
0001-Use-single-snapshot-for-replaying-transaction.patchtext/x-diffDownload+28-61
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