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

Masahiko Sawada <sawada.mshk@gmail.com>

From: Masahiko Sawada <sawada.mshk@gmail.com>

To: Michael Paquier <michael.paquier@gmail.com>

Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@enterprisedb.com>, Amit Kapila <amit.kapila16@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>

Date: 2017-11-30T02:05:16Z

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 →

Allow page lock to conflict among parallel group members.
- 3ba59ccc896e 13.0 landed
Allow relation extension lock to conflict among parallel group members.
- 85f6b49c2c53 13.0 landed
Add assert to ensure that page locks don't participate in deadlock cycle.
- 72e78d831ab5 13.0 landed
Assert that we don't acquire a heavyweight lock on another object after
- 15ef6ff4b985 13.0 landed
Fix unsafe usage of strerror(errno) within ereport().
- 81256cd05f07 11.0 cited

On Thu, Nov 30, 2017 at 10:52 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Wed, Nov 29, 2017 at 5:33 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Sun, Nov 26, 2017 at 9:33 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>>> Attached latest patch incorporated all comments so far. Please review it.
>>
>> I think you only need RelExtLockReleaseAllI() where we currently have
>> LockReleaseAll(DEFAULT_LOCKMETHOD, ...) not where we have
>> LockReleaseAll(USER_LOCKMETHOD, ...).  That's because relation
>> extension locks use the default lock method, not USER_LOCKMETHOD.
>
> Latest review is fresh. I am moving this to next CF with "waiting on
> author" as status.

Thank you Michael-san, I'll submit a latest patch.

Regards,

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