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

From Andres Freund
Subject SyncRepLock acquired exclusively in default configuration
Date
Msg-id 20200406050332.nsscfqjzk2d57zyx@alap3.anarazel.de
Whole thread Raw
Responses Re: SyncRepLock acquired exclusively in default configuration
List pgsql-hackers
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.

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.

Greetings,

Andres Freund

[1] https://postgr.es/m/CABrsG8j3kPD%2Bkbbsx_isEpFvAgaOBNGyGpsqSjQ6L8vwVUaZAQ%40mail.gmail.com



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Reinitialize stack base after fork (for the benefit of rr)?
Next
From: Fabien COELHO
Date:
Subject: Re: backup manifests and contemporaneous buildfarm failures