Re: Autovac cancellation is broken in v14

From: Andres Freund <andres(at)anarazel(dot)de>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>
Subject: Re: Autovac cancellation is broken in v14
Date: 2020-08-27 21:35:06
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2020-08-27 16:20:30 -0400, Jeff Janes wrote:
> On Thu, Aug 27, 2020 at 3:10 PM Jeff Janes <jeff(dot)janes(at)gmail(dot)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?



In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuro Yamada 2020-08-27 23:42:55 Re: list of extended statistics on psql
Previous Message Mark Dilger 2020-08-27 20:41:31 Re: recovering from "found xmin ... from before relfrozenxid ..."