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>
In-Reply-To: <CAAKRu_a04jbDACwzRYwzDND31aPyf7Yvz9TAZrTr=+F5bK1aVA@mail.gmail.com>
From: Kirill Reshke <reshkekirill@gmail.com>
Date: Sun, 4 Jan 2026 02:36:25 +0500
Message-ID: <CALdSSPjcv25jmXm29X-MRWZBae6+HwcWfVH1PE8NfD=EMTnkAg@mail.gmail.com>
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: Chao Li <li.evan.chao@gmail.com>, Xuneng Zhou <xunengzhou@gmail.com>, 
	Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, 
	Andrey Borodin <x4mmm@yandex-team.ru>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CALdSSPjcv25jmXm29X-MRWZBae6%2BHwcWfVH1PE8NfD%3DEMTnkAg%40mail.gmail.com>
Precedence: bulk

On Tue, 23 Dec 2025 at 06:18, Melanie Plageman
<melanieplageman@gmail.com> wrote:
>
> Right, it is totally okay to change function APIs in a major release.
> My point was not that it wasn't allowed but that if people are getting
> useful information returned from that function, or if we think we
> might want that information again in the future, we should think twice
> before changing it. But, in this case, I think we don't need to worry
> about it.
>
> - Melanie

At first glance this change looks sane, and I do not find any reason why
table_scan_analyze_next_tuple needs knowledge about OldestXid. But I am not
aware of this function design discussions, maybe OldestXid is here for
a good reason.

After thinking about it for a week or so, I would actually suggest
moving forward with v31 (Remove OldestXmin from TAM).
I think this is a low probability of getting complaints about that.
Also, we're breaking ABI, so we will know about any important use-case
not long after 19-beta1.
Another user of extensible TAM, Cloudberry [0], does not use
OldestXmin also. I also did not find any user of
scan_analyze_next_tuple other than postgresql itself with
http://codesearch.decbian.net/ . Using code-search on github I found
[1]. Looks like this does not need OldestXmin either.

[0] https://github.com/apache/cloudberry
[1] https://github.com/hydradatabase/columnar/blob/main/columnar/src/backend/columnar/columnar_tableam.c#L2080C68-L2080C78

--
Best regards,
Kirill Reshke