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