Andres Freund <and...@anarazel.de> writes: > I've not yet read the full thread, but I'm a bit confused so far. We > obviously can get changing information about indexes here, but isn't > that something we have to deal with anyway? If we guarantee that we > don't loose knowledge that there's a pending invalidation, why do we > have to retry?
We don't *have to* retry; the core of the fix is to not enter stale data into the cache after we've already received an invalidation signal. The current caller can survive with stale data; or if that's not true, C.I.C. has got more fundamental problems than posited here. But it seems like a generally bad idea for relcache to return data that it knows (or at least has reason to believe) is stale. Also, even if you're okay with return-stale-data-but-don't-cache-it, I have little faith that invalidate_indexattr_v3.patch successfully implements that. Consider the sequence: inval received during RelationGetIndexAttrBitmap, we clear rd_indexvalid, something asks for the relation OID list, we recalculate that and set rd_indexvalid, then we reach the end of RelationGetIndexAttrBitmap and see that rd_indexvalid is set. If that happened, we'd cache the bitmaps whether or not they were really up to date. Now admittedly, it's a bit hard to think of a reason why anything would ask for the index list of anything but a system catalog in that sequence, so as long as you assume that we don't allow C.I.C. (or more realistically, REINDEX CONCURRENTLY) on system catalogs, this failure mode is unreachable. But I much prefer having a positive verification that the index list is still what it was when we started. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers