Re: BUG #18630: Incorrect memory access inside ReindexIsProcessingIndex() on VACUUM
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tender Wang <tndrwang@gmail.com>
Cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2024-09-26T07:01:42Z
Lists: pgsql-bugs
Attachments
- 0001-Remove-invalid-toast-indexes-from-reindex-processing.patch (text/x-diff) patch 0001
On Wed, Sep 25, 2024 at 06:19:20PM +0800, Tender Wang wrote: > Adding if (flags & REINDEX_REL_SUPPRESS_INDEX_USE) check before calling > RemoveReindexPending() may look better. > Any thoughts? The short answer to that is yes, see below. Alexander's trick presented upthread is funky. I was first confused of what was the point until I noticed that this is just a way to make REINDEX CONCURRENTLY fail and produce an invalid toast index. The first pg_sleep causes REINDEX to fail because we are waiting for the first transaction to complete. So this provides a controlled way to get an index that should never be part of the list reported to SetReindexPending() to begin with. The VACUUM (PROCESS_MAIN FALSE, FULL) is then disturbed. Anyway, PROCESS_MAIN is not related to the failure, as it is just a flavor grammar introduced for the sake of making toast-only rebuilds easier for administrators. The same failure reproduces if switching the test case of upthread to do the REINDEX on the toast table, down to 12 which is as far as I have tested because that's what we support around here. Regarding the fix, we should not disturb the list of indexes in a relation returned by relcache.c, and invalid indexes are part of it. So I'd agree with your point to just remove the index from the pending list because we have to skip invalid toast indexes in the reindex_relation() path as reindex_index() has to generate a hard failure because we can never ever have two valid toast indexes, and that's a guarantee we need to be very careful about. Now, about REINDEX_REL_SUPPRESS_INDEX_USE. Well, that's only used for the VACUUM FULL/CLUSTER path which is where the indexes are marked as being processed, so we have to reomve the invalid toast indexes from the list only if this flag is used. Hence the answer is yes. I'd rather keep the informative warning. That's useful for monitoring purposes. Something worth noting while I have looked at this code.. Non-toast invalid indexes are rebuilt but still marked as !indisvalid, actually. That's a waste and we could just skip them for a CLUSTER/VACUUM FULL. This cannot be true for a REINDEX TABLE, invalid indexes are switched to valid in this case. -- Michael
Commits
-
Fix incorrect memory access in VACUUM FULL with invalid toast indexes
- 2f33e68a5c56 12.21 landed
- 911eda9f3cc3 13.17 landed
- 6530b869c302 14.14 landed
- a613edc5c21c 15.9 landed
- afbd3dc7d223 16.5 landed
- 1532599a854a 17.1 landed
- 09620ea09121 18.0 landed