From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Arseny Sher <a(dot)sher(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why chain of snapshots is used in ReorderBufferCommit? |
Date: | 2018-03-01 05:26:26 |
Message-ID: | 20180301052626.5f6hdxvvyncuz73n@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2018-03-01 05:27:19 | Re: PATCH: Unlogged tables re-initialization tests |
Previous Message | Andrey Borodin | 2018-03-01 05:23:41 | Re: Online enabling of checksums |