Re: Forbid to DROP temp tables of other sessions

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Daniil Davydov <3danissimo(at)gmail(dot)com>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Forbid to DROP temp tables of other sessions
Date: 2025-03-17 06:15:51
Message-ID: CAKFQuwZw1GYNjzmtQaG=zJv13knsiKD2u4Fvktsz93Fi4N2zfQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2025-03-17 06:17:59 Re: SQL function which allows to distinguish a server being in point in time recovery mode and an ordinary replica
Previous Message vignesh C 2025-03-17 06:08:08 Re: Use Python "Limited API" in PL/Python