On Tue, 30 Dec 2025 at 00:22, Chao Li <li.evan.chao@gmail.com> wrote:
> I understand that switching to rd_indexcxt is intended to mitigate the risk that external index AMs might still
pallocthe returned IndexAmRoutine.
>
> However, I don’t see a way to actually enforce external AMs to always return a static pointer. In particular, if an
AMswitches 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
wouldrequire detecting dynamically allocated results and copying them into rd_indexcxt, which doesn’t appear easy or
robustto 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
