Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]"): > As Robert pointed out, a read-only transaction cannot normally be > aborted by a serialization failure on COMMIT. Under exceptional > conditions, like an attempt to suppress the serialization failure, > you might see the commit aborted, though.
Thanks for the detailed explanation. Sorry for missing the 2nd example in that page, which does indeed show a read-only transaction failing: However, in that example, as you seem to allude to, there is still a complete serialisation of all the transactions, even the failed T3: T1,T2,T3. The database has detected the problem before returning data in T3 that would contradict the serialisation order. The thing that was puzzling me, after having slept on it, and before I read your mail, was how it could happen that the serialisation failure (of a transaction that did only reads) would only be detected at commit. The point about attempts to suppress the serialisation failure is part of the answer to that. Are there other reasons, besides previously suppressed serialisation failures, why commit of a transaction that did only reads might fail ?  I mean to include transactions which don't update even if they're not explicitly declared `read only', so that the application retained (until it said to commit) the option to try to make changes. Supposing I understand your `doomed' flag correctly, I think it is then probably possible to construct an argument that proves that allowing the application to trap and suppress serialisation failures does not make it harder to provide coherency guarantees. Or to put it another way: does pgsql already detect serialisation problems (in transactions which only read) at the point where it would otherwise return data not consistent with any serialisation order ? (As it does in the `Rollover' example.) If so presumably it always throws a serialisation failure at that point. I think that is then sufficient. There is no need to tell the application programmer they have to commit even transactions which only read. If my supposition is right then I will try to develop this argument more formally. I think that would be worthwhile because the converse property is very surprising to non-database programmers, and would require very explicit documentation by pgsql, and careful attention by application programmers. It would be nice to be able to document a stronger promise. Ian. -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers