Robert Creager <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
