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

  1. pgstat: Fix transactional stats dropping for indexes