From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: XactLockTableWait doesn't set wait_event correctly |
Date: | 2016-12-02 00:35:04 |
Message-ID: | CANP8+j+22krHxLg5qcWqX=thnM-DJ5NkX+ZAz5PCy7kzsXOYUw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2 December 2016 at 00:28, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Nov 30, 2016 at 6:50 AM, Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Karl O. Pinc | 2016-12-02 01:08:41 | Re: Patch to implement pg_current_logfile() function |
Previous Message | Simon Riggs | 2016-12-02 00:31:47 | Re: Proposal for changes to recovery.conf API |