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 |
Message-ID: | 20200827213506.4baaanygq62q7pcj@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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(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?
Regards,
Andres
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 ..." |