Re: SyncRepLock acquired exclusively in default configuration - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: SyncRepLock acquired exclusively in default configuration
Date
Msg-id CA+fd4k4Jd+Ar7iTWiASdt8GNAvv1giD2NDnkjN+yVSjHC1FbLw@mail.gmail.com
Whole thread Raw
In response to SyncRepLock acquired exclusively in default configuration  (Andres Freund <andres@anarazel.de>)
Responses Re: SyncRepLock acquired exclusively in default configuration  (Ashwin Agrawal <aagrawal@pivotal.io>)
List pgsql-hackers
On Mon, 6 Apr 2020 at 14:04, Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> Due to the change below, when using the default postgres configuration
> of ynchronous_commit = on, max_wal_senders = 10, will now acquire a new
> exclusive lwlock after writing a commit record.

Indeed.

>
> commit 48c9f4926562278a2fd2b85e7486c6d11705f177
> Author: Simon Riggs <simon@2ndQuadrant.com>
> Date:   2017-12-29 14:30:33 +0000
>
>     Fix race condition when changing synchronous_standby_names
>
>     A momentary window exists when synchronous_standby_names
>     changes that allows commands issued after the change to
>     continue to act as async until the change becomes visible.
>     Remove the race by using more appropriate test in syncrep.c
>
>     Author: Asim Rama Praveen and Ashwin Agrawal
>     Reported-by: Xin Zhang, Ashwin Agrawal, and Asim Rama Praveen
>     Reviewed-by: Michael Paquier, Masahiko Sawada
>
> As far as I can tell there was no discussion about the added contention
> due this change in the relevant thread [1].
>
> The default configuration has an empty synchronous_standby_names. Before
> this change we'd fall out of SyncRepWaitForLSN() before acquiring
> SyncRepLock in exlusive mode. Now we don't anymore.
>
>
> I'm really not ok with unneccessarily adding an exclusive lock
> acquisition to such a crucial path.
>

I think we can acquire SyncRepLock in share mode once to check
WalSndCtl->sync_standbys_defined and if it's true then check it again
after acquiring it in exclusive mode. But it in turn ends up with
adding one extra LWLockAcquire and LWLockRelease in sync rep path.

Regards,

--
Masahiko Sawada            http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: d25ea01275 and partitionwise join
Next
From: Noah Misch
Date:
Subject: Optimizing RelationFindReplTupleSeq() for CLOBBER_CACHE_ALWAYS