SyncRepLock acquired exclusively in default configuration

Поиск
Список
Период
Сортировка
От Andres Freund
Тема SyncRepLock acquired exclusively in default configuration
Дата
Msg-id 20200406050332.nsscfqjzk2d57zyx@alap3.anarazel.de
обсуждение исходный текст
Ответы Re: SyncRepLock acquired exclusively in default configuration
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Reinitialize stack base after fork (for the benefit of rr)?
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: backup manifests and contemporaneous buildfarm failures