From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) |
Date: | 2025-07-13 18:34:26 |
Message-ID: | BD5C3345-42F2-4870-89B2-FD8875301714@yandex-team.ru |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 12 Jul 2025, at 03:19, Melanie Plageman <melanieplageman(at)gmail(dot)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 will have 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 monitoring reasons, 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 several cases of VM corruptions that might be connected to the fact that we log VM changes independently of data changes that caused VM to change. But I have no real evidence or understanding what happened.
Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | Mankirat Singh | 2025-07-13 18:34:33 | Re: ABI Compliance Checker GSoC Project |
Previous Message | Masahiko Sawada | 2025-07-13 18:28:16 | Re: Make COPY format extendable: Extract COPY TO format implementations |