Re: 7.4Beta1 hang?
От | Tom Lane |
---|---|
Тема | Re: 7.4Beta1 hang? |
Дата | |
Msg-id | 8665.1060478225@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 7.4Beta1 hang? (Robert Creager <Robert_Creager@LogicalChaos.org>) |
Ответы |
Re: 7.4Beta1 hang?
Re: 7.4Beta1 hang? |
Список | pgsql-hackers |
Robert Creager <Robert_Creager@LogicalChaos.org> writes: > [much data] Well, I'm baffled. The vacuum process is evidently waiting for the insert, but I don't think it could be holding any lock that the other two want. The insert is trying to grab a per-buffer lock, which is reasonable. I do not see that the VACUUM could have that lock, but it's possible the checkpoint process does. However, as best I can tell the checkpoint process is trying to get the BufMgrLock, and neither of the other two can be holding that. So what the heck is blocking the checkpoint? A point of interest is that the VACUUM is trying to get the lock on a GIST index (it must be so, as lazy_vacuum_index would not need to get any lock at all on btree indexes). OTOH, the insert is busy trying to insert into one of the btree indexes on obs_i (can't tell which); and furthermore it's trying to do a page split in that index, which is relatively uncommon. It's possible that the combination of these events would reproducibly yield the hang, though I sure don't see how. Could you supply the relation names corresponding to the relation OIDs appearing in pg_locks, so we can be sure who's processing what? After that, we've probably got all the info we can get from this occurrence. Please rebuild with debugging enabled, and hope that it happens again so we can get more data. regards, tom lane
В списке pgsql-hackers по дате отправления: