Re: Excessive CPU usage in StandbyReleaseLocks()

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Excessive CPU usage in StandbyReleaseLocks()
Дата
Msg-id CAEepm=2=ZXp9u7+a6ygiB1jqf9OewxbDzZthNct5BP0ghj94Uw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Excessive CPU usage in StandbyReleaseLocks()  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Thu, Jun 21, 2018 at 10:29 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2018-06-21 00:25:03 +1200, David Rowley wrote:
>> On 19 June 2018 at 17:43, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
>> > The problem is that StandbyReleaseLocks() does a linear search of all
>> > known AccessExclusiveLocks when a transaction ends.  Luckily, since
>> > v10 (commit 9b013dc2) that is skipped for transactions that haven't
>> > taken any AELs and aren't using 2PC, but that doesn't help all users.
>>
>> Good to see this getting fixed.  My original patch [1] to fix this was
>> more along the lines of yours
>
> From that discussion I don't really understand why that wasn't pursued
> further.

I have now pushed this, and back-patched it all the way.  There are
three variants:

* master: as previously posted
* 9.5-10: StandbyReleaseOldLocks() works slightly differently
* 9.3-9.4: minor dynahash API change

The difference in StandbyReleaseOldLocks() is due to recent commit
15378c1a, which I gather was due to be back-patched to REL_10_STABLE
at some stage (so I guess the thing to do will be to copy master's new
StandbyReleaseOldLocks() to 10).  CC: Simon.

I torture tested this for a while on each branch, but of course any
post-commit review or testing would be very welcome.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Non-reserved replication slots and slot advancing
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager