On Sat, Mar 07, 2020 at 04:23:58PM -0500, Tom Lane wrote: > Hmm, seems like a pretty arbitrary (and slow) way to test that. I'd > envision testing that by setting up a case with an expression index > where the expression is designed to fail at some point partway through > the build -- say, with a divide-by-zero triggered by one of the tuples > to be indexed.
I am not sure that I think that's very tricky to get an invalid index _ccold after the swap phase with what the existing test facility provides, because the new index is already built at the point where the dependencies are switched so you cannot rely on a failure when building the index. Note also that some tests of CREATE INDEX CONCURRENTLY rely on the uniqueness to create invalid index entries (division by zero is fine as well). And, actually, if you rely on that, you can get invalid _ccnew entries easily: create table aa (a int); insert into aa values (1),(1); create unique index concurrently aai on aa (a); reindex index concurrently aai; =# \d aa Table "public.aa" Column | Type | Collation | Nullable | Default --------+---------+-----------+----------+--------- a | integer | | | Indexes: "aai" UNIQUE, btree (a) INVALID "aai_ccnew" UNIQUE, btree (a) INVALID That's before the dependency swapping is done though... With a fault injection facility, it would be possible to test the stability of the operation by enforcing for example failures after the start of each inner transaction of REINDEX CONCURRENTLY. -- Michael
signature.asc
Description: PGP signature