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 | BD5C3345-42F2-4870-89B2-FD8875301714@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) (Melanie Plageman <melanieplageman@gmail.com>) |
Ответы |
Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
|
Список | pgsql-hackers |
> On 12 Jul 2025, at 03:19, Melanie Plageman <melanieplageman@gmail.com> wrote: > > remove the xl_heap_visible struct Same goes for VISIBILITYMAP_XLOG_CATALOG_REL and XLOG_HEAP2_VISIBLE. But please do not rush to remove it, perhaps I willhave a more exhaustive list later. Currently the patch set is expected to be unpolished. I just need to absorb all effects to have a high-level evaluation of the patch set effect. I'm still trying to grasp connection of first patch with Assert(prstate->cutoffs) to other patches; 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. So far I do not see any general problems in delegating redo work from xl_heap_visible to other record. FWIW I observed severalcases of VM corruptions that might be connected to the fact that we log VM changes independently of data changes thatcaused VM to change. But I have no real evidence or understanding what happened. Best regards, Andrey Borodin.
В списке pgsql-hackers по дате отправления: