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.
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 |