On Fri, Jul 19, 2019 at 6:47 PM Peter Geoghegan <p...@bowt.ie> wrote: > I believe that the primary reason why certain other database systems > retain locks until rollback completes (or release their locks in > reverse order, as UNDO processing progresses) is that application code > will often repeat exactly the same actions on receiving a transient > error, until the action finally completes successfully. Just like with > serialization failures, or with manually implemented UPSERT loops that > must sometimes retry. This is why UNDO is often (or always) processed > synchronously, blocking progress of the client connection as its xact > rolls back.
I don't think this matters here at all. As long as there's only DML involved, there won't be any lock conflicts anyway - everybody's taking RowExclusiveLock or less, and it's all fine. If you update a row in zheap, abort, and then try to update again before the rollback happens, we'll do a page-at-a-time rollback in the foreground, and proceed with the update; when we get around to applying the undo, we'll notice that page has already been handled and skip the undo records that pertain to it. To get the kinds of problems I'm on about here, somebody's got to be taking some more serious locks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
