From: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Logical decoding of sequence advances, part II |
Date: | 2016-08-22 21:43:40 |
Message-ID: | CACjxUsPvHPSbWJR-BYbGFK6qpT5UMO4e_RkBOauWFR==EHubsQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 22, 2016 at 3:29 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> it seems to me that
> this is just one facet of a much more general problem: given two
> transactions T1 and T2, the order of replay must match the order of
> commit unless you can prove that there are no dependencies between
> them. I don't see why it matters whether the operations are sequence
> operations or data operations; it's just a question of whether they're
> modifying the same "stuff".
The commit order is the simplest and safest *unless* there is a
read-write anti-dependency a/k/a read-write dependency a/k/a
rw-conflict: where a read from one transaction sees the "before"
version of data modified by the other transaction. In such a case
it is necessary for correct serializable transaction behavior for
the transaction that read the "before" image to be replayed before
the write it didn't see, regardless of commit order. If you're not
trying to avoid serialization anomalies, it is less clear to me
what is best.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Flower | 2016-08-22 22:02:43 | Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) |
Previous Message | Andres Freund | 2016-08-22 21:43:33 | Re: Changed SRF in targetlist handling |