On Sunday, March 16, 2025, Daniil Davydov <
3danissimo@gmail.com> wrote:
Hi,
On Sun, Mar 16, 2025 at 7:53 PM vignesh C <vignesh21@gmail.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.
