Re: pgstatindex vs. !indisready

On Sun, Oct 01, 2023 at 04:20:42PM -0700, Peter Geoghegan wrote:
> On Sun, Oct 1, 2023 at 2:00 PM Noah Misch <noah@leadboat.com> wrote:
> > Okay.  If no other preferences appear, I'll do pgstatindex that way.
> 
> Sounds reasonable.
> 
>> [pgstatginindex pgstathashindex pgstattuple] currently succeed.  Like
>> pgstatindex, they should ERROR, including in the back branches.
> 
> Makes sense.

These are already restrictive, makes sense.

>> [brin_desummarize_range brin_summarize_new_values brin_summarize_range
>> gin_clean_pending_list] currently succeed.  I propose to make them emit a
>> DEBUG1 message and return early, like amcheck does, except on !indisready.
>> This would allow users to continue running them on all indexes of the
>> applicable access method.  Doing these operations on an
>> indisready&&!indisvalid index is entirely reasonable, since they relate to
>> INSERT/UPDATE/DELETE operations.

Hmm.  Still slightly incorrect in some cases?  Before being switched
to indisvalid, an index built concurrently may miss some tuples
deleted before the reference snapshot used to build the index was
taken.

> +1 to all that (including the part about these operations being a
> little different to the amcheck functions in one particular respect).

Making them return early sounds sensible here.

> FWIW, amcheck's handling of unlogged relations when in hot standby
> mode is based on the following theory: if recovery were to end, the
> index would become an empty index, so just treat it as if it was
> already empty during recovery. Not everybody thought that this
> behavior was ideal, but ISTM that it has fewer problems than any
> alternative approach you can think of. The same argument works just as
> well with any function that accepts a regclass argument IMV.

It depends, I guess, on how "user-friendly" all that should be.  I
have seen in the past as argument that it may be sometimes better to
have a function do nothing rather than ERROR when these are used
across a scan of pg_class, for example, particularly for non-SRFs.
Even if sometimes errors can be bypassed with more quals on the
relkind or such (aka less complicated queries with less JOINs to
write).
--
Michael