On Thu, Dec 1, 2016 at 7:35 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 2 December 2016 at 00:28, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Nov 30, 2016 at 6:50 AM, Simon Riggs <simon@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