Re: should there be a hard-limit on the number of transactions pending undo?

On Fri, Jul 19, 2019 at 4:14 PM Robert Haas <robertmhaas(at)gmail(dot)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