Re: pg_upgrade fails with an error "object doesn't exist"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Vaibhav Dalvi <vaibhav(dot)dalvi(at)enterprisedb(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pg_upgrade fails with an error "object doesn't exist"
Date: 2025-06-16 13:41:07
Message-ID: 516031.1750081267@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> On 16 Jun 2025, at 09:29, Vaibhav Dalvi <vaibhav(dot)dalvi(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-06-16 13:56:06 Re: No error checking when reading from file using zstd in pg_dump
Previous Message Yugo Nagata 2025-06-16 13:37:43 Re: relrewrite not documented at the top of heap_create_with_catalog()