Horton

Re: Fix bug with accessing to temporary tables of other sessions

Daniil Davydov <3danissimo@gmail.com>

View thread
From: Daniil Davydov <3danissimo@gmail.com>
To: Jim Jones <jim.jones@uni-muenster.de>
Cc: Alexander Korotkov <aekorotkov@gmail.com>, Michael Paquier <michael@paquier.xyz>, Soumya S Murali <soumyamurali.work@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Stepan Neretin <slpmcf@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Mohamed Ali <moali.pg@gmail.com>, Nazneen Jafri <jafrinazneen@gmail.com>, Shawn McCoy <shawn.the.mccoy@gmail.com>
Date: 2026-05-03T08:53:39Z
Lists: pgsql-hackers

Attachments

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