Re: Serializable Transaction Anomoly

You are correct, that is where I made the mistake.
Thank you for the clarification; I understand much better now and the behavior we experienced makes sense with the correct reading of the documentation.

Daniel Bickler

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Date: Tuesday, November 5, 2024 at 2:17 PM
To: Daniel Bickler <daniel(dot)bickler(at)goprominent(dot)com>, pgsql-docs(at)lists(dot)postgresql(dot)org <pgsql-docs(at)lists(dot)postgresql(dot)org>
Subject: Re: Serializable Transaction Anomoly
[You don't often get email from laurenz(dot)albe(at)cybertec(dot)at(dot) Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

On Tue, 2024-11-05 at 18:41 +0000, Daniel Bickler wrote:
> The way I interpreted the documentation, the example I ran into was a false negative
> according to the definition of a serialization anomaly, because it’s serial in one
> ordering but not the other which seems incorrect with “all possible”.
>
> I think where I don’t fully understand is the documentation seems to imply all serial
> orderings must be valid to commit a SERIALIZABLE transaction but it seems like just
> one serial ordering must be valid?

You seem to think that transactions are serializable if their result is consistent
with all possible serial execution orders. But that is not so.

What the documentation says is:
It is an serialization anomaly (that is, not serializable) if the execution is
*in*consistent will all possible serial executions.

That implies: It is serializable if the execution is consistent with one serial
execution.

Yours,
Laurenz Albe