Re: pg_stat_have_stats() returns true for dropped indexes (or for index creation transaction rolled back)
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: "Drouvot, Bertrand" <bdrouvot@amazon.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-08-22T17:36:54Z
Lists: pgsql-hackers
Hi, On 2022-08-22 18:39:07 +0200, Drouvot, Bertrand wrote: > While working on the relation stats split into table and index stats [1], I > noticed that currently pg_stat_have_stats() returns true for dropped indexes > (or for index creation transaction rolled back). Good catch. I guess Horiguchi-san and/or I wrongly assumed it'd be taken care of by the pgstat_create_relation() in heap_create_with_catalog(), but index_create() doesn't use that. > Please find attached a patch proposal to fix it. Perhaps a better fix would be to move the pgstat_create_relation() from heap_create_with_catalog() into heap_create()? Although I guess it's a bit pointless to deduplicate given that you're going to split it up again... > It does contain additional calls to pgstat_create_relation() and > pgstat_drop_relation() as well as additional TAP tests. Would be good to add a test for CREATE INDEX / DROP INDEX / REINDEX CONCURRENTLY as well. Might be worth adding a test to stats.sql or stats.spec in the main regression tests. Perhaps that's best where the aforementioned things should be tested? > @@ -2349,6 +2354,7 @@ index_drop(Oid indexId, bool concurrent, bool concurrent_lock_mode) > CatalogTupleDelete(indexRelation, &tuple->t_self); > > ReleaseSysCache(tuple); > + > table_close(indexRelation, RowExclusiveLock); > > /* Assume this was just an accident? Greetings, Andres Freund
Commits
-
pgstat: Fix transactional stats dropping for indexes
- 43e496e24298 15.0 landed
- d811ce6ea343 16.0 landed