Horton

Re: Forbid to DROP temp tables of other sessions

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: "Andrey M. Borodin" <x4mmm@yandex-team.ru>, Thomas Munro <thomas.munro@gmail.com>
Cc: Daniil Davydov <3danissimo@gmail.com>, Rafia Sabih <rafia.pghackers@gmail.com>, Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2024-11-21T22:02:12Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_basebackup: Add missing PQclear in error path

Hi,

On 2024-11-21 23:52:52 +0300, Andrey M. Borodin wrote:
> I suspect that protection of temp tables was broken by 00d1e02be249.

I think we might have broken this in multiple ways in recent releases. In 17
one can even read the data from the other relation when using a sequential
scan, because that'll go through a streaming read and from there directly to
StartReadBuffers(), bypassing the check in ReadBufferExtended().


> And I'd suggest fixing it in a line with how it worked before. Changes to
> locking mechanism is kind of a super subtle matters, it is really hard to
> bring this checks here without breaking something else. Maybe not
> immidiately. but still. I'd suggest fixing somewhere around
> RelationAddBlocks(). But be sure to check all code pathes that lead to this
> check.

Yea, I don't think the lock approach would work that well.  However, I don't
love having to put RELATION_IS_OTHER_TEMP() checks everywhere either. After
all we seem to have introduced two independent oversights related to this...

I wonder if we could handle this by having a few locations explicitly opt-in
to accessing another database's temp table and erroring out everywhere else -
there's not that many places we need to do so.


> Also, having an isolation test is nice. But do we actually do isolation
> tests with PL\pgSQL?

There are several other tests creating functions. But I think this one goes a
bit too far...


Greetings,

Andres Freund