Re: Fix bug with accessing to temporary tables of other sessions - Mailing list pgsql-hackers

From Daniil Davydov
Subject Re: Fix bug with accessing to temporary tables of other sessions
Date
Msg-id CAJDiXgi_SW3DVvXb4+n04NA1YfeeXmT3gUnSG7h4JwBd+RdJGg@mail.gmail.com
Whole thread
In response to Re: Fix bug with accessing to temporary tables of other sessions  (Jim Jones <jim.jones@uni-muenster.de>)
Responses Re: Fix bug with accessing to temporary tables of other sessions
List pgsql-hackers
Hi,

On Sun, May 3, 2026 at 12:32 AM Jim Jones <jim.jones@uni-muenster.de> wrote:
>
> In addition to the DROP TABLE exception:
>
> It is also possible to LOCK temporary tables from other sessions:
>
> postgres=# BEGIN;
> BEGIN
> postgres=*# LOCK TABLE pg_temp_91.t IN ACCESS SHARE MODE ;
> LOCK TABLE
>
> pg_temp_91.t lives as long the transaction is open -- even after the
> origin session closes, which is totally expected. I'd say it falls into
> the same category of DROP TABLE, where the table contents are never
> read, so I'd argue it's ok.

Autovacuum locks orphaned table's oid before deleting it. LOCK TABLE command
also locks the oid of the specified table. If we want to make sure that
autovacuum can acquire the mentioned lock (i.e. cover this behavior using
tests), I suggest testing it using the LOCK TABLE command.

Please, see the attached patch that ensures that cross-session LOCK TABLE works
properly.

--
Best regards,
Daniil Davydov

Attachment

pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: UPDATE/DELETE FOR PORTION OF fire FOR EACH STATEMENT more than once
Next
From: Chengpeng Yan
Date:
Subject: Re: Add a greedy join search algorithm to handle large join problems