Re: Atomic ops for unlogged LSN

Поиск
Список
Период
Сортировка
От John Morris
Тема Re: Atomic ops for unlogged LSN
Дата
Msg-id BYAPR13MB26777BA0E688ECE294BDE4A6A0AAA@BYAPR13MB2677.namprd13.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Atomic ops for unlogged LSN  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: Atomic ops for unlogged LSN
Re: Atomic ops for unlogged LSN
Список pgsql-hackers

I incorporated your suggestions and added a few more. The changes are mainly related to catching potential errors if some basic assumptions aren’t met.

 

There are basically 3 assumptions. Stating them as conditions we want to avoid.

  • We should not get an unlogged LSN before reading the control file.
  • We should not get an unlogged LSN when shutting down.
  • The unlogged LSN written out during a checkpoint shouldn’t be used.

 

Your suggestion addressed the first problem, and it took only minor changes to address the other two.

 

The essential idea is, we set a value of zero in each of the 3 situations. Then we throw an Assert() If somebody tries to allocate an unlogged LSN with the value zero.

 

I found the comment about cache coherency a bit confusing. We are dealing with a single address, so there should be no memory ordering or coherency issues. (Did I misunderstand?) I see it more as a race condition. Rather than merely explaining why it shouldn’t happen, the new version verifies the assumptions and throws an Assert() if something goes wrong.

 

Вложения

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

Предыдущее
От: Jesper Pedersen
Дата:
Сообщение: Re: 2023-11-09 release announcement draft
Следующее
От: Peter Smith
Дата:
Сообщение: Re: add log messages when replication slots become active and inactive (was Re: Is it worth adding ReplicationSlot active_pid to ReplicationSlotPersistentData?)