Horton

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

Masahiko Sawada <sawada.mshk@gmail.com>

View thread
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Thomas Munro <thomas.munro@enterprisedb.com>, Amit Kapila <amit.kapila16@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-11-14T07:36:09Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow page lock to conflict among parallel group members.

  2. Allow relation extension lock to conflict among parallel group members.

  3. Add assert to ensure that page locks don't participate in deadlock cycle.

  4. Assert that we don't acquire a heavyweight lock on another object after

  5. Fix unsafe usage of strerror(errno) within ereport().

Thank you for pointing out and comments.

On Fri, Nov 10, 2017 at 12:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> No, that's not right.  Now that you mention it, I realize that tuple
>> locks can definitely cause deadlocks.  Example:
>
> Yeah.  Foreign-key-related tuple locks are another rich source of
> examples.
>
>> ... So I don't
>> think we can remove speculative insertion locks from the deadlock
>> detector either.
>
> That scares me too.  I think that relation extension can safely
> be transferred to some lower-level mechanism, because what has to
> be done while holding the lock is circumscribed and below the level
> of database operations (which might need other locks).  These other
> ideas seem a lot riskier.
>
> (But see recent conversation where I discouraged Alvaro from holding
> extension locks across BRIN summarization activity.  We'll need to look
> and make sure that nobody else has had creative ideas like that.)
>

It seems that we should focus on transferring only relation extension
locks as a first step. The page locks would also be safe but it might
require some fundamental changes related to fast insertion, which is
discussed on other thread[1]. Also in this case I think it's better to
focus on relation extension locks so that we can optimize the
lower-level lock mechanism for it.

So I'll update the patch based on the comment I got from Robert before.

[1] https://www.postgresql.org/message-id/CAD21AoBLUSyiYKnTYtSAbC%2BF%3DXDjiaBrOUEGK%2BzUXdQ8owfPKw%40mail.gmail.com

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center