Re: Autovac cancellation is broken in v14
| От | Andres Freund |
|---|---|
| Тема | Re: Autovac cancellation is broken in v14 |
| Дата | |
| Msg-id | 20200827213506.4baaanygq62q7pcj@alap3.anarazel.de обсуждение исходный текст |
| Ответ на | Re: Autovac cancellation is broken in v14 (Jeff Janes <jeff.janes@gmail.com>) |
| Ответы |
Re: Autovac cancellation is broken in v14
|
| Список | 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 по дате отправления: