Re: pgstatindex vs. !indisready

On Sun, Oct 1, 2023 at 2:00 PM Noah Misch <noah(at)leadboat(dot)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.

> [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.

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

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.

--
Peter Geoghegan