From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Moving relation extension locks out of heavyweight lock manager |
Date: | 2017-05-16 16:30:03 |
Message-ID: | CA+TgmoZAWBdAxcE-NVjzt67ZbuGr_1n4iDkomHkzC5AmtG2DwQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, May 13, 2017 at 7:27 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Fri, May 12, 2017 at 9:14 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> On Wed, May 10, 2017 at 8:39 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>>>> ... I'd like to propose to change relation
>>>> extension lock management so that it works using LWLock instead.
>>
>>> That's not a good idea because it'll make the code that executes while
>>> holding that lock noninterruptible.
>>
>> Is that really a problem? We typically only hold it over one kernel call,
>> which ought to be noninterruptible anyway.
>
> During parallel bulk load operations, I think we hold it over multiple
> kernel calls.
We do. Also, RelationGetNumberOfBlocks() is not necessarily only one
kernel call, no? Nor is vm_extend.
Also, it's not just the backend doing the filesystem operation that's
non-interruptible, but also any waiters, right?
Maybe this isn't a big problem, but it does seem to be that it would
be better to avoid it if we can.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-05-16 16:30:29 | Re: COPY FROM STDIN behaviour on end-of-file |
Previous Message | Alexander Kuzmenkov | 2017-05-16 16:18:56 | Re: PoC: full merge join on comparison clause |