On Tue, 30 Dec 2025 at 00:22, Chao Li <[email protected]> wrote: > I understand that switching to rd_indexcxt is intended to mitigate the risk > that external index AMs might still palloc the returned IndexAmRoutine. > > However, I don’t see a way to actually enforce external AMs to always return > a static pointer. In particular, if an AM switches to a different memory > context internally, the MemoryContextSwitchTo() here would not help.
Yes, sadly it's quite difficult to determine whether something is statically allocated. Unlike with palloc'd objects, you can't rely on an always-available header in assert-enabled builds; the best we can do introspection into which OS memory area this allocation is placed; which encroaches on ASan and Valgrind's featureset --- and even that is not necessarily sufficient, as not all compilers may put `static const` -equivalent objects into knowable memory locations. > I’m not sure whether we want to go further than the current approach, but it > seems that fully eliminating the risk would require detecting dynamically > allocated results and copying them into rd_indexcxt, which doesn’t appear > easy or robust to implement in practice. Yes, I don't think there is much more we can do here to protect index AM implementations against this change within Postgres' own tooling without introducing address space detection features more reasonably found in ASan or Valgrind. So I think this is sufficient as a best-effort approach. Kind regards, Matthias van de Meent
