Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)

On Tue, 23 Dec 2025 at 06:18, Melanie Plageman
<melanieplageman(at)gmail(dot)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