Hi, On Mon, Mar 17, 2025 at 1:15 PM David G. Johnston <david.g.johns...@gmail.com> wrote: > > 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. .... Solving the bug is not going to involve adding a new GUC. I don't think it's worth putting this in a separate discussion. Now everything is moving towards the fact that the superuser will be prohibited from changing the temporary tables of other sessions. In fact, he can't do it anyway (except for DROP command) - see [1]. But now the error for INSERT, UPDATE, DELETE and SELECT commands may not surface immediately due to errors in the code. The only question now is whether superuser should be allowed to DROP these other temp tables. Since opinions are divided, I suggested adding a GUC that will only control this feature.
> If they specify the precise pg_temp schema to affect they likely didn’t make > a mistake. Yep, I agree. However, the features of the postgres kernel do not allow the superuser to correctly perform INSERT, UPDATE, DELETE, SELECT operations, because temporary table's pages cannot be stored in shared buffers. > 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. As far as I understand, only superuser and table's owner (within session) can access the temp tables of session. We want CRUD operations to be performed only by the owner. -- Best regards, Daniil Davydov [1] https://www.postgresql.org/message-id/CAJDiXgj6TBzn=6ezx7+9bna9hpbitbu+muv-n3mhen_zs3n...@mail.gmail.com
