| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: We broke the defense against accessing other sessions' temp tables |
| Date: | 2025-10-04 21:36:53 |
| Message-ID: | 1554941.1759613813@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> writes:
> True. I just didn't expect this behavior to extend to temporary tables
> as well. It was just a bit surprising that a temporary table can persist
> after its owning session ends, simply because another session is holding
> a lock on it --- without the owning session being aware of that.
Actually the owning session is perfectly aware of that: it's waiting
on the lock to be released so it can finish dropping its temp tables.
The *client* likely isn't aware, because usually clients just close
the connection without waiting for end-of-session cleanup to happen.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2025-10-05 00:56:44 | Re: Teaching planner to short-circuit empty UNION/EXCEPT/INTERSECT inputs |
| Previous Message | Jim Jones | 2025-10-04 21:07:33 | Re: We broke the defense against accessing other sessions' temp tables |