Re: pgstatindex vs. !indisready - Mailing list pgsql-hackers

From Noah Misch
Subject Re: pgstatindex vs. !indisready
Date
Msg-id 20231022210245.2f.nmisch@google.com
Whole thread Raw
In response to Re: pgstatindex vs. !indisready  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pgstatindex vs. !indisready
List pgsql-hackers
On Wed, Oct 04, 2023 at 09:00:23AM +0900, Michael Paquier wrote:
> On Sun, Oct 01, 2023 at 06:31:26PM -0700, Noah Misch wrote:
> > The !indisvalid index may be missing tuples, yes.  In what way does that make
> > one of those four operations incorrect?
> 
> Reminding myself of what these four do, it looks that you're right and
> that the state of indisvalid is not going to change what they report.
> 
> Still, I'd like to agree with Tom's point to be more conservative and
> check also for indisvalid which is what the planner does.  These
> functions will be used in SELECTs, and one thing that worries me is
> that checks based on indisready may get copy-pasted somewhere else,
> leading to incorrect results where they get copied.  (indisready &&
> !indisvalid) is a "short"-term combination in a concurrent build
> process, as well (depends on how long one waits for the old snapshots
> before switching indisvalid, but that's way shorter than the period of
> time where the built indexes remain valid).

Neither choice would harm the user experience in an important way, so I've
followed your preference in the attached patch.

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Guiding principle for dropping LLVM versions?
Next
From: jian he
Date:
Subject: Re: UniqueKey v2