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

On Thu, Mar 26, 2026 at 12:07 PM Tomas Vondra <tomas(at)vondra(dot)me> wrote:
>
> >> Ah, so we expect people to invent their "own" flags, outside what's in
> >> ScanOptions? Or do I misunderstand how it works? (I admit not reading
> >> the whole massive thread, as I was only interested in using the flags in
> >> my own patch.)
> >
> > Yes, this isn't really explored in the rest of the thread. I thought
> > since the flags are threaded all the way through and they can
> > set/check the flags in the table AM-specific layer, it would make
> > sense that they could choose flags for their own purposes. They don't
> > have to wait for consensus on getting a new SO type added. I don't
> > know if this is a bad idea. However, changing the table AM wrappers
> > seems more justifiable if we are making them extensible in this way.
> >
>
> No idea. Do we have an example of a TAM actually needing this? If not,
> I'd probably advise to remove that and keep the patch simpler. My past
> attempts to future-proof a patch like this rarely worked.

Yea, not allowing that doesn't really simplify the patch.
But, talking to Andres off-list yesterday, he reminded me that users
can simply add a new member to their table access method-specific scan
descriptor (e.g. HeapScanDescData could get a new member). The value
of flags lies in enabling table AM-agnostic executor code to pass
flags through the table AM to the scan code. Besides my read-only hint
scan option, he gave some examples -- like a hint to the scan that
there is a LIMIT on the query. I think that is compelling.

While exploring this, I realized that for a few internal flags, such
as SO_ALLOW_STRAT and SO_ALLOW_SYNC, we have table scan functions,
like table_beginscan_strat(), that accept parameters for setting those
flags. They are basically the same as table_beginscan() but give users
control over those flags. I think we can use the flags parameter to
deprecate some of these specialized table scan functions. I think we
can simplify the scan_rescan() callback as well. I don't think it
makes sense to do it this late in the 19 release, though. All of those
changes require having a flags parameter in the top level scan
wrappers first. So, I think it is reasonable to do just that this
release.

- Melanie