Nikhil Sontakke <nikhil.sontakke@enterprisedb.com> writes:
> It looked familiar, so I dug up the archives and found that Tom had
> committed a fix for a similar deadlock via git commitid: 715120e7
> However this current deadlock involved an index with oid 2663, which
> is ClassNameNspIndexId. Clearly this was another case of locking the
> index directly without taking a lock on the parent catalog. Further
> sleuthing revealed that the culprit function was InitCatCachePhase2,
> which directly calls index_open in the process startup phase.
Patch applied, thanks!
I did a bit of extra digging around the cache modules and could not find
any other instances of the same problem, though I did find some places
that seemed worthy of a comment about how they avoid it.
regards, tom lane
