I guess the preceding posts leave us with these guarantees about
read-only transactions which we might want to make explicit in the
documentation:
(1) A serialization failure cannot be initially thrown on a COMMIT
attempt for a read-only transaction; however, if a subtransaction
catches a serialization failure exception on a statement within the
transaction, and doesn't re-throw it or throw any other error which
terminates the transaction, the serialization failure can show up
on the COMMIT attempt. (NOTE: We may want to check whether the
"doomed" flag is set on a write conflict for a serializable
transaction. It seems to me that it should be, but that might have
been missed. If so, that should be treated as a bug and fixed.)
(2) A read-only transaction cannot show results inconsistent with
already-committed transactions, so there is no chance of needing to
discard results from a read-only transaction due to failure of the
transaction to commit.
Both of these should hold for both explicit read-only transactions
(which are set to READ ONLY after a BEGIN or START, or due to
default_transaction_read_only being set tot true and not
overridden), and implicit read-only transactions. It is still
worthwhile to explicitly set serializable transactions to read-only
whenever possible, for performance reasons.
The idea that a serialization failure is not possible on the first
(or only) statement o a read-only transaction was in error, and
should be disregarded.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company