MIME-Version: 1.0
References: 
 <CAAKRu_ZMw6Npd_qm2KM+FwQ3cMOMx1Dh3VMhp8-V7SOLxdK9-g@mail.gmail.com>
 <CAAKRu_YXP1Us41fkZJeBK5SSj5whNC0C9fZNT6Brdtm+F0agpg@mail.gmail.com>
 <CAAKRu_bAR5uCfjuc06vc_xrZjNCJLs493NgHjTOUDso9qGdE0w@mail.gmail.com>
 <CAAKRu_ac4vUdU-U3ax8j=N8y2OM9-pbFZhafLVfzDOM8MtzvvA@mail.gmail.com>
 <BD5C3345-42F2-4870-89B2-FD8875301714@yandex-team.ru>
In-Reply-To: <BD5C3345-42F2-4870-89B2-FD8875301714@yandex-team.ru>
From: Melanie Plageman <melanieplageman@gmail.com>
Date: Sun, 13 Jul 2025 15:15:22 -0400
Message-ID: 
 <CAAKRu_a-aVGxNEdkJt+96HGryQXuQNuXe+PhR0KcnUhXSOPBJw@mail.gmail.com>
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM
 on-access)
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Andres Freund <andres@anarazel.de>,
	Robert Haas <robertmhaas@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAAKRu_a-aVGxNEdkJt%2B96HGryQXuQNuXe%2BPhR0KcnUhXSOPBJw%40mail.gmail.com>
Precedence: bulk

On Sun, Jul 13, 2025 at 2:34=E2=80=AFPM Andrey Borodin <x4mmm@yandex-team.r=
u> wrote:
>
> > 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 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 actually did remove those if you check the last version posted. I
did notice there is one remaining comment referring to
XLOG_HEAP2_VISIBLE I missed somehow, but the actual enums/macros were
removed already.

> I'm still trying to grasp connection of first patch with Assert(prstate->=
cutoffs) to other patches;

I added this because I noticed that it was used without validating it
was provided in that location. The last patch in the set which sets
the VM on access changes where cutoffs are used, so I noticed what I
felt was a missing assert in master while developing that page.

> Also, I'd prefer "page is not marked all-visible but visibility map bit i=
s set in relation" to emit XX001 for monitoring reasons, 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?

- Melanie