Re: Is the unfair lwlock behavior intended?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, Ants Aasma <ants(dot)aasma(at)eesti(dot)ee>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Is the unfair lwlock behavior intended?
Date: 2016-05-25 21:24:22
Message-ID: CA+TgmoYo+PJVQd1jG8Uc_rNGO0qDRmf22cvApTj4G-do=ZtfHg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 25, 2016 at 3:26 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2016-05-25 11:15:37 -0700, Andres Freund wrote:
>> On 2016-05-25 14:09:43 -0400, Robert Haas wrote:
>> I don't think anybody was doing that? The first questions on this thread
>> were about upgrading and retesting...
>
> Something I've repeatedly wondered about around this topic is whether we
> could split ProcArrayLock into one that governs entering or leaving the
> procarray from the one that's for consistent snapshots. I think there's
> no need for ProcArrayAdd/ProcArrayRemove/CountDBBackends()/CancelDBBackends()/
> CountUserBackends()/CountOtherDBBackends() (and potentially some more)
> to conflict with GetSnapshotData()/ProcArrayEndTransaction()/
> TransactionIdIsInProgress()/TransactionIdIsActive()/GetOldestXmin()/...
> as long as we're careful to ensure that by the time a entry is removed
> ProcArrayEndTransaction() has been called.

I'm doubtful about how much that would reduce contention, because when
I've used perf or inserted instrumentation to see which actual call
sides are the problem, it's always been entirely down to
GetSnapshotData() and ProcArrayEndTransaction(). However, I think it
might be worth doing anyway, because redesigning the whole mechanism
might be easier if that lock weren't doing so many only-semi-related
things.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-05-25 21:49:20 Re: Is the unfair lwlock behavior intended?
Previous Message Tom Lane 2016-05-25 20:55:23 Re: Changed SRF in targetlist handling