On Fri, Jul 19, 2019 at 4:14 PM Robert Haas <robertmh...@gmail.com> wrote: > 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.
If I'm not mistaken, you're tacitly assuming that you'll always be using zheap, or something sufficiently similar to zheap. It'll probably never be possible to UNDO changes to something like a GIN index on a zheap table, because you can never do that with sensible concurrency/deadlock behavior. I don't necessarily have a problem with that. I don't pretend to understand how much of a problem it is. Obviously it partially depends on what your ambitions are for this infrastructure. Still, assuming that I have it right, ISTM that UNDO/zheap/whatever should explicitly own this restriction. -- Peter Geoghegan
