On Fri, Jul 19, 2019 at 2:57 PM Peter Geoghegan <pg@bowt.ie> wrote:
> On Fri, Jul 19, 2019 at 10:28 AM Robert Haas <robertmhaas@gmail.com> wrote:
> > In scenario #2, the undo work is going to have to be retried in the
> > background, and perforce that means reacquiring locks that have been
> > released, and so there is a chance of long lock waits and/or deadlock
> > that cannot really be avoided.
>
> I haven't studied the UNDO or zheap stuff in any detail, but I am
> concerned about rollbacks that deadlock. I'd feel a lot better about
> it if forward progress was guaranteed, somehow. That seems to imply
> that locks are retained, which is probably massively inconvenient to
> ensure. Not least because it probably requires cooperation from
> underlying access methods.
Right, that's definitely a big part of the concern here, but I don't
really believe that retaining locks is absolutely required, or even
necessarily desirable. For instance, suppose that I create a table,
bulk-load a whole lotta data into it, and then abort. Further support
that by the time we start trying to process the undo in the
background, we can't get the lock. Well, that probably means somebody
is performing DDL on the table. If they just did LOCK TABLE or ALTER
TABLE SET STATISTICS, we are going to need to execute that same undo
once the DDL is complete. However, if the DDL is DROP TABLE, we're
going to find that once we can get the lock, the undo is obsolete, and
we don't need to worry about it any more. Had we made it 100% certain
that the DROP TABLE couldn't go through until the undo was performed,
we could avoid having to worry about the undo having become obsolete
... but that's hardly a win. We're better off allowing the drop and
then just chucking the undo.
Likely, something like CLUSTER or VACUUM FULL would take care of
removing any rows created by aborted transactions along the way, so
the undo could be thrown away afterwards without processing it.
Point being - there's at least some chance that the operations which
block forward progress also represent progress of another sort.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
