Re: XactLockTableWait doesn't set wait_event correctly
От | Simon Riggs |
---|---|
Тема | Re: XactLockTableWait doesn't set wait_event correctly |
Дата | |
Msg-id | CANP8+j+22krHxLg5qcWqX=thnM-DJ5NkX+ZAz5PCy7kzsXOYUw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: XactLockTableWait doesn't set wait_event correctly (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: XactLockTableWait doesn't set wait_event correctly
|
Список | pgsql-hackers |
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? 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. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: