| From: | "T, Adesh" <adeshdb(at)amazon(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, shihao zhong <zhong950419(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "ilmari(at)ilmari(dot)org" <ilmari(at)ilmari(dot)org> |
| Subject: | Re: [PG19] pg_upgrade --check passes, then the upgrade fails |
| Date: | 2026-10-30 17:43:03 |
| Message-ID: | SACPR18MB28916173BA2C27CB74FA4CFF57DE6D2@SACPR18MB289161.namprd18.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi all,
One more case for the general check in master: privileges granted on a
GUC that the new version removed (pg_parameter_acl). pg_upgrade --check
passes, and the globals restore then fails.
Repro, REL_18_STABLE (03ba8e5) -> master (328a9a1):
-- old cluster (18)
CREATE ROLE r1;
GRANT SET ON PARAMETER escape_string_warning TO r1;
$ pg_upgrade ... --check
*Clusters are compatible*
$ pg_upgrade ...
Restoring global objects in the new cluster *failure*
GRANT SET ON PARAMETER "escape_string_warning" TO "r1";
ERROR: unrecognized configuration parameter "escape_string_warning"
The same grant on work_mem upgrades fine, and revoking the grant before
the upgrade avoids the failure.
agree it does not need to block 19. But when the generic check for
stored settings is done, it seems worth reading pg_parameter_acl as well
as pg_db_role_setting.
Regards,
Adesh
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Burd | 2026-10-30 17:46:02 | Re: Quickselect instead of a heap for ORDER BY ... LIMIT N large bounded sorts |
| Previous Message | Greg Burd | 2026-10-30 17:21:03 | Re: Hash index: stop registering pin-only bucket pages in WAL (remove REGBUF_NO_CHANGE) |