Re: Do not lock temp relations

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 <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Maxim Orlov <orlovmg(at)gmail(dot)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
>
>
>
>
>