Re: pg_upgrade fails with an error "object doesn't exist"
От | Vaibhav Dalvi |
---|---|
Тема | Re: pg_upgrade fails with an error "object doesn't exist" |
Дата | |
Msg-id | CA+vB=AH_bkQUycP+V1f-vOvUCjpdDzV7qm5ZLimCqnTXtshU7Q@mail.gmail.com обсуждение исходный текст |
Ответ на | pg_upgrade fails with an error "object doesn't exist" (Vaibhav Dalvi <vaibhav.dalvi@enterprisedb.com>) |
Ответы |
Re: pg_upgrade fails with an error "object doesn't exist"
|
Список | pgsql-hackers |
Hi Tom,
Should we at least restrict dumping privileges for user objects inside pg_catalog to avoid pg_upgrade failure?
Regards,
Vaibhav
On Mon, Jun 16, 2025 at 7:11 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Daniel Gustafsson <daniel@yesql.se> writes:
> On 16 Jun 2025, at 09:29, Vaibhav Dalvi <vaibhav.dalvi@enterprisedb.com> wrote:
>> Why can't we strictly restrict object creation in pg_catalog?
> Do you have allow_system_table_mods set to ON by any chance? As Laurenz said,
> such creation is already restricted, but it can be circumvented by using said
> GUC (which is *not* intended for production usage).
I think that setting only applies to creating or modifying *tables*,
not functions. The point of it is to keep you from breaking the C
code's assumptions about the layout of system catalogs.
Having said that, I don't see a problem here. You're not going
to be able to create/modify functions in pg_catalog unless you
are superuser (or a superuser gave you permissions you shouldn't
have). There are already a near-infinite number of ways
for a superuser to break the system, so this one isn't making it
detectably worse. Furthermore, there are legitimate use-cases
for adding/changing functions there. (I recall that the old
"adminpack" extension used to do so, for example, and there are
probably others that still do.)
regards, tom lane
В списке pgsql-hackers по дате отправления: