On Wed, Dec 14, 2016 at 11:20 AM, Ian Jackson <ian.jackson@eu.citrix.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