| From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Subject: | Re: pg_upgrade allows itself to be run twice |
| Date: | 2022-09-05 17:03:22 |
| Message-ID: | 20220905170322.GM31833@telsasoft.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
rebased and updated
Robert thought that it might be reasonable for someone to initdb, and
then connect and make some modifications, and then pg_upgrade.
https://www.postgresql.org/message-id/CA%2BTgmoYwaXh_wRRa2CqL4XpM4r6YEbq1%2Bec%3D%2B8b7Dr7-T_tT%2BQ%40mail.gmail.com
But the DBs are dropped by pg_upgrade, so that seems to serve no
purpose, except for shared relations (and global objects?). In the case
of shared relations, it seems unsafe (even though my test didn't cause
an immediate explosion).
So rather than continuing to allow arbitrary changes between initdb and
pg_upgrade, I propose to prohibit all changes. I'd consider allowing an
"inclusive" list of allowable changes, if someone were to propose such a
thing - but since DBs are dropped, I'm not sure what it could include.
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-wip-initdb-should-advance-the-OID-counter-to-Firs.patch | text/x-diff | 4.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-09-05 17:18:48 | Re: Remove dead macro exec_subplan_get_plan |
| Previous Message | Nikita Malakhov | 2022-09-05 16:51:32 | Re: Table AM modifications to accept column projection lists |