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

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: konstantin knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
Date: 2018-06-05 10:09:08
Message-ID: CAPpHfdt_HFxNKFbSUaDg5QHxzKcvPBB5OhRengRpVDp6ubdrFg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 5, 2018 at 12:48 PM Konstantin Knizhnik
<k(dot)knizhnik(at)postgrespro(dot)ru> wrote:
> Workload is combination of inserts and selects.
> Looks like shared locks obtained by select cause starvation of inserts, trying to get exclusive relation extension lock.
> The problem is fixed by fair lwlock patch, implemented by Alexander Korotkov. This patch prevents granting of shared lock if wait queue is not empty.
> May be we should use this patch or find some other way to prevent starvation of writers on relation extension locks for such workloads.

Fair lwlock patch really fixed starvation of exclusive lwlock waiters.
But that starvation happens not on relation extension lock – selects
don't get shared relation extension lock. The real issue there was
not relation extension lock itself, but the time spent inside this
lock. It appears that buffer replacement happening inside relation
extension lock is affected by starvation on exclusive buffer mapping
lwlocks and buffer content lwlocks, caused by many concurrent shared
lockers. So, fair lwlock patch have no direct influence to relation
extension lock, which is naturally not even lwlock...

I'll post fair lwlock path in a separate thread. It requires detailed
consideration and benchmarking, because there is a risk of regression
on specific workloads.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2018-06-05 10:10:32 Re: Problem while updating a foreign table pointing to a partitioned table on foreign server
Previous Message Konstantin Knizhnik 2018-06-05 09:47:47 Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager