On Mon, 30 Sept 2024 at 18:05, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Yes. Our implementation restrictions preclude access to the contents > of another session's temp tables, but it is not forbidden to do DDL > on them so long as no content access is required. (Without this, > it'd be problematic for example to clean out a crashed session's temp
> tables. See the "orphan temporary tables" logic in autovacuum.c.)
Indeed, a potentially dangerous situation may arise when both the autovacuum and client process attempt to delete the contents of a temporary namespace. But there is a patch (6faca9ae2878c8f642a2e5748d2dbb2b91341bec)thatprotectsusfrom race condition in this case.
Maxim Orlov <orlovmg@gmail.com> writes: > But for the second one: do we really need any lock for temp relations?
Yes. Our implementation restrictions preclude access to the contents of another session's temp tables, but it is not forbidden to do DDL on them so long as no content access is required. (Without this, it'd be problematic for example to clean out a crashed session's temp tables. See the "orphan temporary tables" logic in autovacuum.c.) You need fairly realistic locking to ensure that's OK.
