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

From: Daniil Davydov <3danissimo(at)gmail(dot)com>
To: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Soumya S Murali <soumyamurali(dot)work(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stepan Neretin <slpmcf(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Mohamed Ali <moali(dot)pg(at)gmail(dot)com>, Nazneen Jafri <jafrinazneen(at)gmail(dot)com>, Shawn McCoy <shawn(dot)the(dot)mccoy(at)gmail(dot)com>
Subject: Re: Fix bug with accessing to temporary tables of other sessions
Date: 2026-05-03 08:53:39
Message-ID: CAJDiXgi_SW3DVvXb4+n04NA1YfeeXmT3gUnSG7h4JwBd+RdJGg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Sun, May 3, 2026 at 12:32 AM Jim Jones <jim(dot)jones(at)uni-muenster(dot)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 Content-Type Size
0001-Test-cross-session-LOCK-TABLE-scenario.patch text/x-patch 2.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chengpeng Yan 2026-05-03 12:46:46 Re: Add a greedy join search algorithm to handle large join problems
Previous Message Thom Brown 2026-05-03 08:24:50 Re: UPDATE/DELETE FOR PORTION OF fire FOR EACH STATEMENT more than once