Awhile back we did some significant rejiggering to ensure that no
relcache load would be attempted without holding at least
AccessShareLock on the relation. (Otherwise, if someone else
is in process of making an update to one of the system catalog
rows defining the relation, there's a race condition for SnapshotNow
scans: the new row version might not be committed when you scan it,
and if you come to the old row version second, it could be committed
dead by the time you scan it, and then you don't see the row at all.)
While thinking about Darren Reed's repeat trouble report
http://archives.postgresql.org/pgsql-admin/2008-04/msg00113.php
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.
AFAICS this doesn't explain Darren's problem because it would only
be a transient failure at the instant of committing the REINDEX;
and whatever he's being burnt by has persistent effects. Nonetheless
it sure looks like a bug. Anyone think it isn't necessary to lock
the target relation here?
regards, tom lane
