From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pgstatindex vs. !indisready |
Date: | 2023-10-01 20:37:25 |
Message-ID: | 1867127.1696192645@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2023-10-01 20:58:30 | Re: pgstatindex vs. !indisready |
Previous Message | Noah Misch | 2023-10-01 19:53:09 | pgstatindex vs. !indisready |