pgstatindex vs. !indisready - Mailing list pgsql-hackers

From Noah Misch
Subject pgstatindex vs. !indisready
Date
Msg-id 20231001195309.a3@google.com
Whole thread Raw
Responses Re: pgstatindex vs. !indisready
List pgsql-hackers
Running pgstatindex on some !indisready indexes fails with "ERROR:  XX001:
could not read block 0 in file".  This reproduces it:

begin;
drop table if exists not_indisready_t;
create table not_indisready_t (c int);
insert into not_indisready_t values (1),(1);
commit;
create unique index concurrently not_indisready_i on not_indisready_t(c);
begin;
create extension pgstattuple;
\set VERBOSITY verbose
select * from pgstatindex('not_indisready_i');
\set VERBOSITY default
rollback;

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

This made me wonder about functions handling unlogged rels during recovery.  I
used the attached hack to test most regclass-arg functions.  While some of
these errors from src/test/recovery/tmp_check/log/001_stream_rep_standby_2.log
may deserve improvement, there were no class-XX messages:

2023-10-01 12:24:05.992 PDT [646914:11] 001_stream_rep.pl ERROR:  58P01: could not open file "base/5/16862": No such
fileor directory
 
2023-10-01 12:24:05.996 PDT [646914:118] 001_stream_rep.pl ERROR:  22023: fork "main" does not exist for this relation

Thanks,
nm

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Evaluate arguments of correlated SubPlans in the referencing ExprState
Next
From: Tom Lane
Date:
Subject: Re: pgstatindex vs. !indisready