Re: Autovaccuum vs temp tables crash
От | Tom Lane |
---|---|
Тема | Re: Autovaccuum vs temp tables crash |
Дата | |
Msg-id | 6584.1550937047@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Autovaccuum vs temp tables crash (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Autovaccuum vs temp tables crash
|
Список | pgsql-hackers |
Magnus Hagander <magnus@hagander.net> writes: > On Fri, Feb 22, 2019 at 7:15 PM Robert Haas <robertmhaas@gmail.com> wrote: >> On Fri, Feb 22, 2019 at 1:14 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Note that all the temp schemas are made as owned by the bootstrap >>> superuser, so there is no real argument to be made that people might >>> be expecting they should be able to delete them. >> Hmm, well maybe you're right. Just seems like an odd wart. > Well, the way it works now is you can drop them. But if you then create > another temp table in the same session, it will get an oid of the already > dropped schema in the relnamespace column. Only if you're superuser. > That just seems plain broken. There are a *lot* of ways that a superuser can break things. I'm not real sure that this one is special enough that we need a defense against it. However, if someone held a gun to my head and said fix it, I'd be inclined to do so by having temp-namespace creation insert a "pin" dependency into pg_depend. Arguably, the only reason we don't create all the temp namespaces during bootstrap is because we aren't sure how many we'd need --- but if we did do that, they'd presumably end up pinned. > I wonder if other "fun" things could happen if you go rename the namespace, > haven't tried that yet... I put that one on exactly a par with renaming all the "=" operators. Yes, the system will let a superuser do it, and no, it's not a good idea. regards, tom lane
В списке pgsql-hackers по дате отправления: