| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: VACUUM FULL deadlock with backend startup |
| Date: | 2011-03-22 17:03:30 |
| Message-ID: | 1155.1300813410@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Nikhil Sontakke <nikhil(dot)sontakke(at)enterprisedb(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nikhil Sontakke | 2011-03-22 17:55:31 | Re: VACUUM FULL deadlock with backend startup |
| Previous Message | Andrew Dunstan | 2011-03-22 17:00:08 | Re: 2nd Level Buffer Cache |