Re: pg_stat_have_stats() returns true for dropped indexes (or for index creation transaction rolled back)

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: bdrouvot(at)amazon(dot)com
Cc: andres(at)anarazel(dot)de, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pg_stat_have_stats() returns true for dropped indexes (or for index creation transaction rolled back)
Date: 2022-08-25 02:47:27
Message-ID: 20220825.114727.330127256246111733.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)amazon(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2022-08-25 03:38:34 Re: use ARM intrinsics in pg_lfind32() where available
Previous Message Tom Lane 2022-08-25 02:30:56 Re: pg_regress: lookup shellprog in $PATH