Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)

Поиск
Список
Период
Сортировка
От Andrey Borodin
Тема Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
Дата
Msg-id 87DD95AA-274F-4F4F-BAD9-7738E5B1F905@yandex-team.ru
обсуждение исходный текст
Ответ на Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)  (Melanie Plageman <melanieplageman@gmail.com>)
Список pgsql-hackers

> On 14 Jul 2025, at 00:15, Melanie Plageman <melanieplageman@gmail.com> wrote:
>
>>
>> Also, I'd prefer "page is not marked all-visible but visibility map bit is set in relation" to emit XX001 for
monitoringreasons, but again, this is small note, while I need a broader picture. 
>
> Could you clarify what you mean by this? Are you talking about the
> string representation of the visibility map bits in the WAL record
> representations in heapdesc.c?

This might be a bit off-topic for this thread, but as long as the patch touches that code we can look into this too.

If VM bit all-visible is set while page is not all-visible IndexOnlyScan will show incorrect results. I observed this
inconsistencyfew times on production. 

Two persistent subsystems (VM and heap) contradict each other, that's why I think this is a data corruption. Yes, we
canrepair the VM by assuming heap to be the source of truth in this case. But we must also emit ERRCODE_DATA_CORRUPTED
XX001code into the logs. In many cases this will alert on-call SRE. 

To do so I propose to replace elog(WARNING,...) with ereport(WARNING,(errcode(ERRCODE_DATA_CORRUPTED),..).


Best regards, Andrey Borodin.


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