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) that protects us from race condition in this case. -- Best regards, Daniil Davydov On Tue, Oct 22, 2024 at 5:55 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Maxim Orlov <orlo...@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. > > regards, tom lane > > > > >
