Re: BUG with accessing to temporary tables of other sessions still exists

Hi,

On Sun, Jun 21, 2026 at 3:08 PM ZizhuanLiu X-MAN <44973863@qq.com> wrote:
>
> Thank you very much for your feedback, as well as the original patch and test cases.
> I have learned a lot about the internals of temporary tables from this discussion.
>
> First, I would like to clarify that the buffer manager is not limited to `bufmgr.c` alone,
> but covers all source files under the `storage/buffer` directory.
>
> I’ve analyzed the existing architecture and the relationship between `bufmgr.c`,
> the `RELATION_IS_OTHER_TEMP` macro and `localbuf.c`, and my observations
> are summarised below:
>
> 1. Within the `storage/buffer` module, `RELATION_IS_OTHER_TEMP` is currently referenced
> in three places, all of which reside in `bufmgr.c`; there are no usages in `localbuf.c` at present.
>
> 2. Looking at the function call graph between `bufmgr.c` and `localbuf.c`, most routines in
> `localbuf.c` serve as helper functions invoked from `bufmgr.c`. (A tiny number of calls exist
> within `src/test/modules/test_io.c`, which I believe can be disregarded for this discussion.)
>
> 3. Under the current design, `localbuf.c` acts as a callee layer focused solely on implementing
> core logic without introducing `RELATION_IS_OTHER_TEMP` checks, keeping this module clean.
> All access validation decisions using `RELATION_IS_OTHER_TEMP` are handled upstream in
> `bufmgr.c` as the main caller.
>
> 4. Placing the `RELATION_IS_OTHER_TEMP` check inside `ExtendBufferedRelCommon()` in `bufmgr.c`
> (rather than `ExtendBufferedRelLocal()` in `localbuf.c`) aligns with this existing architectural principle:
> validation rules are enforced by the caller layer. Admittedly, this approach has a downside — if new
> caller entrypoints are added in the future, each would need to remember to perform this security check.
> Fortunately, all relevant call paths currently originate from `bufmgr.c`.

OK, now I see your point, thank you.

I agree that localbuf.c is a "callee layer focused solely on implementing core
logic". Personally, I don't think that this fact somehow prevents us from
performing some checks related to the temporary table inside localbuf.c, even
if they look like some kind of "top-level" logic.

But we already have an example where RELATION_IS_OTHER_TEMP is processed inside
a function common to local and regular tables - PrefetchBuffer. I'll move the
RELATION_IS_OTHER_TEMP into the bufmgr.c in order to be consistent with an
existing pattern.

Thank you for pointing it out! Please, see proposed change in the v3 patch.

--
Best regards,
Daniil Davydov