On Wed, Jan 13, 2010 at 7:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So basically what this boils down to is that load_critical_index is
> locking an index before locking its underlying relation, which generally
> speaking is against our coding rules. The relcache code has been like
> that since 8.2, so I'm a bit surprised that we have not seen this
> reported before. It could only happen when the relcache init file is
> missing, which isn't the normal state, but it's not exactly unusual
> either.
>
> Probably the appropriate fix is to make load_critical_index get
> AccessShare lock on the underlying catalog not only the index it's
> after. This would slow things down a tad, but since it's not in the
> normal startup path I don't think that matters.
>
> Should we back-patch this? The bug appears to be real back to 8.2,
> but if we've not noticed before, I'm not sure how important it is.
Does this create a problem combined with the plan to allow the new
VACUUM FULL to rewrite system tables? From my brief scan it sounds
like the only reason there's no race condition here is that previously
the oid of system tables couldn't change out from under
load_critical_index. If instead it's possible for them to would it be
possible for it to try to load this index, find the oid of the
underlying table, then go to lock the underlying table only to find it
had been vacuumed out from under it and no longer exists?
--
greg