"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Basically, in a SERIALIZABLE transaction, if the first statement
> which would require a snapshot would currently fail with "ERROR:
> could not serialize access due to concurrent update" we would
> instead get a fresh snapshot and retry -- which is what we do in a
> READ COMMITTED transaction.
This sounds like a pretty horrid kluge. For one thing, the statement
might already have done a great deal of work before you hit the failure.
(Admittedly, that work will be lost anyway if we abort, but it's not
a localized change to make it all happen all over again.) Also,
aborting that statement without also losing any previously-acquired
locks would require establishing a hidden subtransaction, with ensuing
extra costs to be paid even when there isn't a failure.
I think you misunderstand how READ COMMITTED works; it does not change
the snapshot for the entire statement, it only follows the update chain
for a particular tuple that's been chosen for update or delete.
> I'm assuming that this could be a fairly small change
It would not be.
regards, tom lane
