On Thu, Dec 1, 2016 at 7:35 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 2 December 2016 at 00:28, Robert Haas <robertmh...@gmail.com> wrote: >> On Wed, Nov 30, 2016 at 6:50 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >>> Obtaining a tuple lock requires two separate actions: First we do >>> LockTuple() and then we do XactLockTableWait(). >> >> I think that's kind of a confusing way of looking at it. LockTuple() >> waits for a "tuple" lmgr lock, and XactLockTableWait waits for a >> "transaction" lmgr lock. Those two things are both part of a larger >> protocol for managing access to what we refer to as tuple locks at the >> SQL level. I don't think conflating those things would be a very good >> idea, because it's useful to know which phase you're currently doing - >> e.g. anybody waiting on a tuple lock is not first in the queue. > > Why is it useful to know which phase you're at? What can I do with that info?
Well, I just mentioned one thing you can do with it... > Why is knowing that you're doing a "transaction lock" more important > than the fact you're doing a tuple lock on a particular db, relation, > page and tuple? The "transaction lock" tells you nothing a user can > act upon to improve the situation. I think the charter of pg_locks is to provide visibility into what's actually going on in the lock table. It could be useful to provide additional supplementary information as well, if we can do that in a reasonable way, but I think trying to paper over the fact that internally it's a transaction lock probably isn't a good idea. For example, suppose next week somebody decides to replace the "waiting" column in pg_locks with a column indicating the position in the lock queue, with NULL indicating a granted lock. Well, if transaction locks look like tuple locks, the person writing that patch will find it impossible to display something sane in those cases, because the transaction lock queue is separate from the tuple lock queue and you can't somehow glue those together without distorting what the lock manager is actually doing. That kind of thing is the natural consequence of displaying something other than what the system is actually doing internally. But I have no objection to you adding supplementary detail also. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers