Re: [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]

On Wed, Dec 14, 2016 at 11:20 AM, Ian Jackson <ian(dot)jackson(at)eu(dot)citrix(dot)com> wrote:
>> I'm not sure Ian is intentionally taking that position. Not all of us
>> are as familiar with the ramifications of every serializability
>> behavior we may want as you are.
>
> Indeed. I think it's fair to say that I'm totally unfamiliar with the
> ramifications. You might also fairly characterise me as naive; I had
> certainly made some assumptions which it seems are known (around here)
> to be both false and difficult to make true.

We can't all be database gurus...

> Let me try to summarise my understanding of what the developers think
> they can and intend to promise, about SERIALIZABLE transactions:
>
> There is a consistent serialisation of all transactions which
> successfully commit; or which do not attempt to make any changes.

I think we've figured out that it is limited to transactions which
successfully commit plus read-only transactions that roll back at the
top level but never roll back a subtransaction. And I'm not sure
there aren't other exceptions. Basically, be very wary about relying
on information extracted from a transaction that rolled back: there
might be dragons there.

> A "consistent serialisation" means that there is an order in which
> the same transactions might have been executed giving exactly the
> answers. This includes, if applicable, the same errors. (The
> database is free to generate synchronisation failure errors 40P01 and
> 40001 whenever it chooses.)

Seems right.

> A transaction which attempts to make any changes, and which does not
> commit (whether because the application never asks for COMMIT, or
> because of reported synchronisation failure) might see internally
> inconsistent data, or an internally-consistent view which is not
> compatible with any serialisation of other transactions. An
> application which needs a coherent view should not rely on any of the
> information from such a transaction.

I think it will see an internally-consistent view which is not
compatible with any global serial ordering. I don't see why it would
see an internally-inconsistent view; inconsistent how?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company