From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: pgstatindex vs. !indisready
In-reply-to: <20231001195309.a3@google.com>
References: <20231001195309.a3@google.com>
Comments: In-reply-to Noah Misch <noah@leadboat.com>
	message dated "Sun, 01 Oct 2023 12:53:09 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1867126.1696192645.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 01 Oct 2023 16:37:25 -0400
Message-ID: <1867127.1696192645@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1867127.1696192645%40sss.pgh.pa.us>
Precedence: bulk

Noah Misch <noah@leadboat.com> writes:
> Running pgstatindex on some !indisready indexes fails with "ERROR:  XX00=
1:
> could not read block 0 in file".  This reproduces it:
> ...
> Since XX001 =3D ERRCODE_DATA_CORRUPTED appears in the "can't-happen" cla=
ss, it's
> not a good fit for this scenario.  I propose to have pgstatindex fail ea=
rly on
> !indisready indexes.

+1

> We could go a step further and also fail on
> indisready&&!indisvalid indexes, which are complete enough to accept ins=
erts
> but not complete enough to answer queries.  I don't see a reason to do t=
hat,
> 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.

			regards, tom lane