Re: Autovac cancellation is broken in v14
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, David Rowley <dgrowleyml@gmail.com>
Date: 2020-08-27T21:35:06Z
Lists: pgsql-hackers
Hi, On 2020-08-27 16:20:30 -0400, Jeff Janes wrote: > On Thu, Aug 27, 2020 at 3:10 PM Jeff Janes <jeff.janes@gmail.com> wrote: > > > If I create a large table with "CREATE TABLE ... AS SELECT ... from > > generate_series(1,3e7)" with no explicit transactions, then once it is done > > I wait for autovac to kick in, then when I try to build an index on that > > table (or drop the table) the autovac doesn't go away on its own. > > > > After a bit more poking at this, I think we are checking if we ourselves > are an autovac process, not doing the intended check of whether the other > guy is one. Ugh, good catch. > Where would be a good spot to add a regression test for this? > "isolation_regression" ? I'm not immediately sure how we could write a good test for this, particularly not in the isolation tests. We'd basically have to make sure that a table needs autovacuuming, then sleep for long enough for autovacuum to have come around, and block autovacuum from making progress. That latter is doable by holding a pin on a page it needs to freeze, e.g. using a cursor. I suspect all of that would at least require a TAP test, and might still be too fragile. Other ideas? Regards, Andres
Commits
-
Fix autovacuum cancellation.
- 5871f09c9858 14.0 landed
-
snapshot scalability: Move PGXACT->vacuumFlags to ProcGlobal->vacuumFlags.
- 5788e258bb26 14.0 cited