Re: Why chain of snapshots is used in ReorderBufferCommit?
От | Andres Freund |
---|---|
Тема | Re: Why chain of snapshots is used in ReorderBufferCommit? |
Дата | |
Msg-id | 20180301052626.5f6hdxvvyncuz73n@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Why chain of snapshots is used in ReorderBufferCommit? (Arseny Sher <a.sher@postgrespro.ru>) |
Ответы |
Re: Why chain of snapshots is used in ReorderBufferCommit?
|
Список | 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 по дате отправления: