Re: pg_stat_have_stats() returns true for dropped indexes (or for index creation transaction rolled back) - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: pg_stat_have_stats() returns true for dropped indexes (or for index creation transaction rolled back)
Date
Msg-id 20220825.114727.330127256246111733.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: pg_stat_have_stats() returns true for dropped indexes (or for index creation transaction rolled back)  ("Drouvot, Bertrand" <bdrouvot@amazon.com>)
Responses Re: pg_stat_have_stats() returns true for dropped indexes (or for index creation transaction rolled back)
List pgsql-hackers
Good catch, and thanks for the patch!

(The file name would correctly be v2-0001-...:)

At Tue, 23 Aug 2022 09:58:03 +0200, "Drouvot, Bertrand" <bdrouvot@amazon.com> wrote in 
> Agree it's better to move it to heap_create(): it's done in the new
> version attached.

+1 (not considering stats splitting)

> We'll see later on if it needs to be duplicated for the table/index
> split work.

The code changes looks good to me.

> >> 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?
> 
> Yeah that sounds better, I'm also adding more tests around table
> creation while at it.
> 
> I ended up adding the new tests in stats.sql.

+-- pg_stat_have_stats returns true for table creation inserting data
+-- pg_stat_have_stats returns true for committed index creation
+

Not sure we need this, as we check that already in the same file. (In
other words, if we failed this, the should have failed earlier.) Maybe
we only need check for drop operations and reindex cases?

We have other variable-numbered stats kinds
FUNCTION/REPLSLOT/SUBSCRIPTION. Don't we need the same for these?

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_regress: lookup shellprog in $PATH
Next
From: John Naylor
Date:
Subject: Re: use ARM intrinsics in pg_lfind32() where available