Re: Autovac cancellation is broken in v14 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Autovac cancellation is broken in v14
Date
Msg-id 20200827213506.4baaanygq62q7pcj@alap3.anarazel.de
Whole thread Raw
In response to Re: Autovac cancellation is broken in v14  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: Autovac cancellation is broken in v14
List 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



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: recovering from "found xmin ... from before relfrozenxid ..."
Next
From: Tatsuro Yamada
Date:
Subject: Re: list of extended statistics on psql