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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vaibhav Dalvi <vaibhav(dot)dalvi(at)enterprisedb(dot)com>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, 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-17 02:58:04
Message-ID: 719363.1750129084@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Vaibhav Dalvi <vaibhav(dot)dalvi(at)enterprisedb(dot)com> writes:
> Should we at least restrict dumping privileges for user objects inside
> pg_catalog to avoid pg_upgrade failure?

You haven't made a credible case for us to add any complexity in this
area. Anybody messing with pg_catalog is living very much in "if you
break it, you get to keep both pieces" territory. That extends not
just to whether the backend works at all, but whether auxiliary
functionality such as pg_dump works. So in particular I don't see
a reason why we should cater to manually-added pg_catalog functions
with non-default ACLs. There are enough moving parts in that area
already that I'm not eager to add more constraints to what pg_dump
needs to do.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2025-06-17 03:06:26 Re: BackendKeyData is mandatory?
Previous Message vignesh C 2025-06-17 02:54:41 Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly