Re: [BUG] Cannot flush buffers of temp table deleted from other session
От | Daniil Davydov |
---|---|
Тема | Re: [BUG] Cannot flush buffers of temp table deleted from other session |
Дата | |
Msg-id | CAJDiXgiyh94aG2x6BaWzq1tTGifw9yoGKQLykSL49-sxQB6nbg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUG] Cannot flush buffers of temp table deleted from other session (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Hi, On Thu, Jun 12, 2025 at 2:40 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Daniil Davydov <3danissimo@gmail.com> writes: > > Ability to do a DROP temporary table of other session leads to error : > > [ shrug... ] Don't do that. A superuser is capable of doing lots > of things that will break the database, and this one hardly seems > like one of the worse ones. OK, I see your point, thanks. IMHO, deleting other temporary tables and (for example) deleting rows from pg_class are not so similar in terms of the obvious occurrence of bad consequences. But as far as I understand, we will not specify such details somewhere in the documentation. > > > BTW, there are other bugs that can occur during interacting with other > > session temp tables. I described them and suggested corrections in > > this thread [1]. > > I doubt I'd agree that any such thing is a bug we need to fix. > You should not be attempting to touch other sessions' temp tables. > (If there's any path by which a non-superuser can do that, we > probably need to tighten some permission check somewhere.) Let's forget about DROP for a while. Postgres design has rules, that superuser cannot perform commands like select/update/delete/truncate... with other session's temp tables. You can find appropriate error messages (for example) in bufmgr.c : *** if (RELATION_IS_OTHER_TEMP(reln)) ereport(ERROR, (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), errmsg("cannot access temporary tables of other sessions"))); *** But by now the query parser does not recognize other session's temp tables as temporary, and we can get weird query results instead of getting the error provided by the postgres design (that even worse than unexpected error occurrence). I am sure that this is a bug and we should fix such behavior. -- Best regards, Danill Davydov
В списке pgsql-hackers по дате отправления: