Re: Why chain of snapshots is used in ReorderBufferCommit? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Why chain of snapshots is used in ReorderBufferCommit?
Date
Msg-id 20180301052626.5f6hdxvvyncuz73n@alap3.anarazel.de
Whole thread Raw
In response to Why chain of snapshots is used in ReorderBufferCommit?  (Arseny Sher <a.sher@postgrespro.ru>)
Responses Re: Why chain of snapshots is used in ReorderBufferCommit?  (Arseny Sher <a.sher@postgrespro.ru>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: Online enabling of checksums
Next
From: Thomas Munro
Date:
Subject: Re: PATCH: Unlogged tables re-initialization tests