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: Robert Haas <robertmhaas@gmail.com>
Cc: 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-12-13T07:02:45Z
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().

On Wed, Dec 13, 2017 at 12:42 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Dec 11, 2017 at 4:10 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>> Thank you for updating the patch. Here is two minor comments.
>>
>> + * we acquire the same relation extension lock repeatedly.  nLocks is 0 is the
>> + * number of times we've acquired that lock;
>>
>> Should it be "nLocks is the number of times we've acquired that lock:"?
>
> Yes.
>
>> +    /* Remember lock held by this backend */
>> +    held_relextlock.relid = relid;
>> +    held_relextlock.lock = relextlock;
>> +    held_relextlock.nLocks = 1;
>>
>> We set held_relextlock.relid and held_relextlock.lock again. Can we remove them?
>
> Yes.
>
> Can you also try the experiment Andres mentions: "Measure two COPYs to
> relations on different filesystems, reduce N_RELEXTLOCK_ENTS to 1, and
> measure performance.

Yes. I'll measure the performance on such environment.

> Then increase the concurrency of the copies to
> each relation."  We want to see whether and how much this regresses
> performance in that case.  It simulates the case of a hash collision.
>

When we add extra blocks on a relation do we access to the disk? I
guess we just call lseek and write and don't access to the disk. If so
the performance degradation regression might not be much.

Regards,

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