Re: pgstatindex vs. !indisready
Noah Misch <noah@leadboat.com>
From: Noah Misch <noah@leadboat.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Peter Geoghegan <pg@bowt.ie>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2023-10-22T21:02:45Z
Lists: pgsql-hackers
Attachments
- indisvalid-funcs-v1.patch (text/plain) patch v1
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.
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