aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist
diff options
context:
space:
mode:
authorMichael Paquier <michael@paquier.xyz>2023-07-14 10:13:14 +0900
committerMichael Paquier <michael@paquier.xyz>2023-07-14 10:13:14 +0900
commit31f9d41d625dc6ca8c1469edd6919316b18174fe (patch)
tree466db5c9901980b7b0ff0f6e098da2702c49f287 /src/backend/access/gist
parenta4b4cc1d60f7e8ccfcc8ff8cb80c28ee411ad9a9 (diff)
downloadpostgresql-31f9d41d625dc6ca8c1469edd6919316b18174fe.tar.gz
postgresql-31f9d41d625dc6ca8c1469edd6919316b18174fe.zip
Fix updates of indisvalid for partitioned indexes
indisvalid is switched to true for partitioned indexes when all its partitions have valid indexes when attaching a new partition, up to the top-most parent if all its leaves are themselves valid when dealing with multiple layers of partitions. The copy of the tuple from pg_index used to switch indisvalid to true came from the relation cache, which is incorrect. Particularly, in the case reported by Shruthi Gowda, executing a series of commands in a single transaction would cause the validation of partitioned indexes to use an incorrect version of a pg_index tuple, as indexes are reloaded after an invalidation request with RelationReloadIndexInfo(), a much faster version than a full index cache rebuild. In this case, the limited information updated in the cache leads to an incorrect version of the tuple used. One of the symptoms reported was the following error, with a replica identity update, for instance: "ERROR: attempted to update invisible tuple" This is incorrect since 8b08f7d, so backpatch all the way down. Reported-by: Shruthi Gowda Author: Michael Paquier Reviewed-by: Shruthi Gowda, Dilip Kumar Discussion: https://postgr.es/m/CAASxf_PBcxax0wW-3gErUyftZ0XrCs3Lrpuhq4-Z3Fak1DoW7Q@mail.gmail.com Backpatch-through: 11
Diffstat (limited to 'src/backend/access/gist')
0 files changed, 0 insertions, 0 deletions