Re: Why chain of snapshots is used in ReorderBufferCommit?

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


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:

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

In response to


Browse pgsql-hackers by date

  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