SyncRepLock acquired exclusively in default configuration

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org, Simon Riggs <simon(at)2ndquadrant(dot)com>, Ashwin Agrawal <aagrawal(at)pivotal(dot)io>, Xin Zhang <xzhang(at)pivotal(dot)io>, Asim Praveen <apraveen(at)pivotal(dot)io>
Subject: SyncRepLock acquired exclusively in default configuration
Date: 2020-04-06 05:03:32
Message-ID: 20200406050332.nsscfqjzk2d57zyx@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndQuadrant(dot)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2020-04-06 05:18:10 Re: backup manifests and contemporaneous buildfarm failures
Previous Message Peter Geoghegan 2020-04-06 04:40:34 Re: Reinitialize stack base after fork (for the benefit of rr)?