I wrote:
> I realized that we failed to plug all the gaps of this type,
> because relcache.c contains *internal* cache load/reload operations
> that aren't protected. In particular the LOAD_CRIT_INDEX macro
> calls invoke relcache load on indexes that aren't locked. So they'd
> be at risk from a concurrent REINDEX or similar on those system
> indexes. RelationReloadIndexInfo seems at risk as well.
On closer analysis, LOAD_CRIT_INDEX is clearly broken here, but the
other places I was worried about seem safe, because they are all
used to rebuild relcache entries that are being held open by
higher-level code; and the contract is that there should be a lock
protecting any open relcache entry.
I've committed a fix that adds locking to LOAD_CRIT_INDEX and adds
some comments about the other cases.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
