"Kevin Grittner" <kevin.gritt...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers