From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mikhail Gribkov <youzhick(at)gmail(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Accessing other session's temp table |
Date: | 2024-11-20 22:47:37 |
Message-ID: | 260666.1732142857@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mikhail Gribkov <youzhick(at)gmail(dot)com> writes:
> What do you think?
I think this will break cases we don't want to break.
Accessing the metadata of other temp tables is fine, and indeed
necessary for operations like dropping them. It's access to
the table contents that needs to be blocked. I'm surprised
that we don't have sufficient tests at that level.
[ experiments... ] It looks like this did work as expected up
through v15. So somebody broke it fairly recently, perhaps
as a side effect of the table-AM work. Might be worth bisecting
to see where it broke.
(Realistically though, this is all only a problem for superusers,
who are supposed to Know Better. For ordinary users the permissions
set on temp schemas ought to be enough to prevent such things.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2024-11-20 23:24:30 | Re: UUID v7 |
Previous Message | David Steele | 2024-11-20 22:44:36 | Re: Return pg_control from pg_backup_stop(). |