From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Daniil Davydov <3danissimo(at)gmail(dot)com>, Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Forbid to DROP temp tables of other sessions |
Date: | 2024-11-21 22:02:12 |
Message-ID: | 4xxau766dofbwugeyvjftra3g5f7ifaal2clgrbpr7jqotr4av@d3ige2krpoza |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Erik Wienhold | 2024-11-21 22:05:27 | Re: circle @> box, polygon points access |
Previous Message | Joe Conway | 2024-11-21 21:39:58 | Re: Replace current implementations in crypt() and gen_salt() to OpenSSL |