Re: Forbid to DROP temp tables of other sessions
От | Andres Freund |
---|---|
Тема | Re: Forbid to DROP temp tables of other sessions |
Дата | |
Msg-id | 4xxau766dofbwugeyvjftra3g5f7ifaal2clgrbpr7jqotr4av@d3ige2krpoza обсуждение исходный текст |
Ответ на | Re: Forbid to DROP temp tables of other sessions ("Andrey M. Borodin" <x4mmm@yandex-team.ru>) |
Ответы |
Re: Forbid to DROP temp tables of other sessions
|
Список | 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
В списке pgsql-hackers по дате отправления: