Re: Decouple last important WAL record LSN from WAL insert locks

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Decouple last important WAL record LSN from WAL insert locks
Дата
Msg-id 20221126211336.y57vh746f5bat5h3@awork3.anarazel.de
обсуждение исходный текст
Ответ на Decouple last important WAL record LSN from WAL insert locks  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Ответы Re: Decouple last important WAL record LSN from WAL insert locks  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Список pgsql-hackers
Hi,

On 2022-11-23 19:12:07 +0530, Bharath Rupireddy wrote:
> While working on something else, I noticed that each WAL insert lock
> tracks its own last important WAL record's LSN (lastImportantAt) and
> both the bgwriter and checkpointer later computes the max
> value/server-wide last important WAL record's LSN via
> GetLastImportantRecPtr(). While doing so, each WAL insertion lock is
> acquired in exclusive mode in a for loop. This seems like too much
> overhead to me.

GetLastImportantRecPtr() should be a very rare operation, so it's fine for it
to be expensive. The important thing is for the maintenance of the underlying
data to be very cheap.


> I quickly coded a patch (attached herewith) that
> tracks the server-wide last important WAL record's LSN in
> XLogCtlInsert (lastImportantPos) protected with a spinlock and gets
> rid of lastImportantAt from each WAL insert lock.

That strikes me as a very bad idea. It adds another point of contention to a
very very hot code path, to make a very rare code path cheaper.

Greetings,

Andres Freund



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: MSVC vs Perl
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Allow processes to reset procArrayGroupNext themselves instead of leader resetting for all the followers