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
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)? |