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 <alvhe...@alvh.no-ip.org> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers