Re: pgstatindex vs. !indisready

On Sun, Oct 01, 2023 at 04:37:25PM -0400, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
> > Running pgstatindex on some !indisready indexes fails with "ERROR: XX001:
> > could not read block 0 in file". This reproduces it:
> > ...
> > Since XX001 = ERRCODE_DATA_CORRUPTED appears in the "can't-happen" class, it's
> > not a good fit for this scenario. I propose to have pgstatindex fail early on
> > !indisready indexes.
>
> +1
>
> > We could go a step further and also fail on
> > indisready&&!indisvalid indexes, which are complete enough to accept inserts
> > but not complete enough to answer queries. I don't see a reason to do that,
> > but maybe someone else will.
>
> Hmm. Seems like the numbers pgstatindex would produce for a
> not-yet-complete index would be rather irrelevant, even if the case
> doesn't risk any outright problems. I'd be inclined to be
> conservative and insist on indisvalid being true too.

Okay. If no other preferences appear, I'll do pgstatindex that way.

> > This made me wonder about functions handling unlogged rels during recovery. I
> > used the attached hack to test most regclass-arg functions.

I forgot to test the same battery of functions on !indisready indexes. I've
now done that, using the attached script. While I didn't get additional
class-XX errors, more should change:

[pgstatginindex pgstathashindex pgstattuple] currently succeed. Like
pgstatindex, they should ERROR, including in the back branches.

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

[pg_freespace pg_indexes_size pg_prewarm] currently succeed, and I propose to
leave them that way. No undefined behavior arises. pg_freespace needs to be
resilient to garbage data anyway, given the lack of WAL for the FSM. One
could argue for a relkind check in pg_indexes_size. One could argue for
treating pg_prewarm like amcheck (DEBUG1 and return).