Re: Forbid to DROP temp tables of other sessions

On Sunday, March 16, 2025, Daniil Davydov <3danissimo(at)gmail(dot)com> wrote:

> Hi,
>
> On Sun, Mar 16, 2025 at 7:53 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> > I noticed that the following Andrey's comment regarding the isolation
> > test from [1] and Andres's comment from [2] are pending. I'm changing
> > the commitfest entry to Waiting on Author, please provide an updated
> > patch and update it to Needs review.
>
> Thanks for reading it.
> I saw [2] and introduced a possible solution in my last letter. In
> short : we can have a GUC variable that will permit superuser to drop
> temp tables of other sessions. Thus, we have a single location in code
> that will check whether we can perform operations with other temp
> tables. As far as I understand, this is exactly what Andres wrote
> about.
>

It’s seems like the bug “session A can read and write to session B’s
tables” has gotten lost in this thread that pertains to something related
but different. I strongly suggest you break out a new thread for this bug
with an attention-getting subject line. Seems we should be fixing that
without regards to how to refactor this area of the code (maybe we did, I
haven’t followed or am able to experiment right now…just reading this
thread).

Solving the bug is not going to involve adding a new GUC. I don’t really
see how a GUC helps here at all - the superuser shouldn’t need to opt-in
they could always do before. If they specify the precise pg_temp schema to
affect they likely didn’t make a mistake. The feature is a no-go if it
only applies to superuser anyway. If instead we are discussing the owner
of the temporary table there is probably a discussion to be had and
decision to be documented somewhere - maybe that central place of testing
being wished for.

David J.