Hi,
When we lock on a Xid or VirtualXid, there's no way to obtain clear
information on the reason for locking. Consider the following example:
CREATE TABLE foo (a int);
Session 1:
BEGIN;
SELECT 1;
-- we now have a snapshot
Session 2:
CREATE INDEX CONCURRENTLY foo_a ON foo(a);
This blocks until transaction 1 commits, and it's not obvious to the
user the reason for this. There's some info in pg_locks but it just
says it's blocked in a VirtualXid.
A much more common ocurrence is tuple locks. We block in an Xid in that
case; and this has been a frequent question in the mailing lists and
IRC.
I think it would be very nice to be able to report something to the
user; however, I'm not seeing the mechanism.
A simple idea I had was that each backend would have a reserved shared
memory area where they would write what they are about to lock, when
locking an Xid or VXid. Thus, if they block, someone else can examine
that and make the situation clearer. The problem with this idea is that
it would require locking a LWLock just before trying each lock on
Xid/VXid, which would be horrible for performance.
... or maybe not, because when we call XactLockTableWait, we've already
established that we've accepted to sleep.
Thoughts?
--
Álvaro Herrera <alvherre@alvh.no-ip.org>
