Re: pgstatindex vs. !indisready
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Noah Misch <noah@leadboat.com>
Cc: Peter Geoghegan <pg@bowt.ie>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2023-10-04T00:00:23Z
Lists: pgsql-hackers
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). -- Michael
Commits
-
Diagnose !indisvalid in more SQL functions.
- bae063db499f 11.22 landed
- 975ae05537fa 12.17 landed
- 123b0d111511 13.13 landed
- 0a7b183fdc1b 14.10 landed
- e633e9b132ff 15.5 landed
- 1a368dd3ecef 16.1 landed
- 13503eb5905b 17.0 landed