MIME-Version: 1.0
References: <CAAKRu_ZP-3=SaZykpwDBMJOdUKyW3Wm5JZfPFRR3L5Ac8ouq4w@mail.gmail.com>
 <CAAKRu_bgkOQqu3K5n4YLRsNBZqJ9Rjg80ROqgKSr2UGz4b5hUg@mail.gmail.com>
 <2wk7jo4m4qwh5sn33pfgerdjfujebbccsmmlownybddbh6nawl@mdyyqpqzxjek>
 <CAAKRu_YR-COJ9aGnMUQqt5yoWmUBjikqrd4jGNZYouHaXpis9g@mail.gmail.com>
 <CALdSSPhiCwJwWwgJP1NmqRmnp9RS2tGOBY0gQrfLCbB+OS5_KQ@mail.gmail.com>
 <CAAKRu_YS+Ocm=OzMaZnG4egFiE9v4VYfZ25DXd6jbwegqmGYbQ@mail.gmail.com>
 <CAAKRu_ZGZSqhGt-RcmmfiSheC+1fjQdxy6_+oM-1jMn8hyVptQ@mail.gmail.com>
 <CALdSSPg+B8RTzTXhJvCcKJBqgzhPZkq0E2oqxQdv74ZNZOMVzg@mail.gmail.com>
 <CAAKRu_Zha7HcdQBv8tTtQrcry5332J6kHnOc1X=TT03LzUXDow@mail.gmail.com>
 <CAAKRu_amF00f2T_H8N6pbbe75C22EeX1OqA=svpj8LNO1sdUuw@mail.gmail.com>
 <mhf4vkmh3j57zx7vuxp4jagtdzwhu3573pgfpmnjwqa6i6yj5y@sy4ymcdtdklo>
 <CAAKRu_agCLAQ9OjmrTdJe-X=Xr7QnU4d=cfxdQGwc9jNx9w31w@mail.gmail.com>
 <CAAKRu_ayWLg=WDGZZfSPWf0KjPM8u=LBb0D6XaEWyx2_YFFwAQ@mail.gmail.com>
 <CABPTF7X1X810eT7hjRz9M69sjMv1Vui5gXQEGhqYXmkmywhHCQ@mail.gmail.com>
 <CAAKRu_ZcK+ez71W7j+QzMo0gSafTsbGA3TU-fVSptw7yh41BEQ@mail.gmail.com>
 <6BC5DBAB-6084-4BB8-8450-52E9648AB021@gmail.com> <CAAKRu_ZCjHoRPfQ8AbMrFY8TOMCPAvZ0_m9SX7yg0edfTk45-g@mail.gmail.com>
 <7F5BCD7A-764D-4D8D-8E27-6F2CAAEA1CEE@gmail.com> <CAAKRu_a04jbDACwzRYwzDND31aPyf7Yvz9TAZrTr=+F5bK1aVA@mail.gmail.com>
 <CALdSSPjcv25jmXm29X-MRWZBae6+HwcWfVH1PE8NfD=EMTnkAg@mail.gmail.com>
 <CAAKRu_bwtBEzDwemyim1r6yYonw7FTyFr1HXG8vywCe-MdbPBQ@mail.gmail.com>
 <4379FDA3-9446-4E2C-9C15-32EFE8D4F31B@yandex-team.ru> <CAAKRu_YQd=2KvomM+RHcpeDKj0bq+peJ=3W-fip+pkvzA-Jq9w@mail.gmail.com>
 <EEA21113-8A6B-4CB3-BE49-6299F513469A@gmail.com>
In-Reply-To: <EEA21113-8A6B-4CB3-BE49-6299F513469A@gmail.com>
From: Melanie Plageman <melanieplageman@gmail.com>
Date: Tue, 27 Jan 2026 17:58:33 -0500
Message-ID: <CAAKRu_ZkhzypqsmPb69n1YgE=rPbuKtV2h1BwBXyqMzSymsv3Q@mail.gmail.com>
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
To: Chao Li <li.evan.chao@gmail.com>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, Kirill Reshke <reshkekirill@gmail.com>, 
	Xuneng Zhou <xunengzhou@gmail.com>, Andres Freund <andres@anarazel.de>, 
	Robert Haas <robertmhaas@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAAKRu_ZkhzypqsmPb69n1YgE%3DrPbuKtV2h1BwBXyqMzSymsv3Q%40mail.gmail.com>
Precedence: bulk

On Wed, Jan 7, 2026 at 3:15=E2=80=AFAM Chao Li <li.evan.chao@gmail.com> wro=
te:
>
> I believe the reason why we add Assert(TransactionIdIsValid(dead_after)) =
under HEAPTUPLE_RECENTLY_DEAD is to ensure that when HeapTupleSatisfiesVacu=
umHorizon() returns HEAPTUPLE_RECENTLY_DEAD, dead_after must be set. So the=
 goal of the assert is to catch bugs of HeapTupleSatisfiesVacuumHorizon().
>
> From this perspective, I now feel dead_after should be initialized to Inv=
alidTransactionId. Otherwise, say HeapTupleSatisfiesVacuumHorizon() has a b=
ug and miss to set dead_after, then the assert mostly like won=E2=80=99t be=
 fired, because it holds a random value, most likely not be 0.

Actually, thinking about it more, I decided to remove the assertions
on dead_after from those patches entirely. I don't use dead_after and
only pass it in because HeapTupleSatisfiesVacuumHorizon requires it.
In fact, I don't care if the function correctly sets dead_after since
I don't use it.

> +       /* set if the query doesn't modify the rel */
> +       SO_HINT_REL_READ_ONLY =3D 1 << 10,
> ```
>
> Nit: I think it=E2=80=99s better to replace =E2=80=9Crel=E2=80=9D to =E2=
=80=9Crelation=E2=80=9D. For a function comment, if there is a parameter na=
med =E2=80=9Crel=E2=80=9D, then we can use it to refer to the parameter, wi=
thout such a context, I guess here a while word is better.

k

I'm currently working on a new version that incorporates Andres'
review feedback and will post soon.

- Melanie