|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||Justin Pryzby <pryzby(at)telsasoft(dot)com>|
|Cc:||Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org|
|Subject:||Re: pg_upgrade allows itself to be run twice|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Fri, Dec 16, 2022 at 07:38:09AM -0600, Justin Pryzby wrote:
> However, setting FirstNormalOid in initdb itself (rather than in the
> next invocation of postgres, if it isn't in single-user-mode) was the
> mechanism by which to avoid the original problem that pg_upgrade can be
> run twice, if there are no non-system relations. That still seems
> desirable to fix somehow.
+ if (new_cluster.controldata.chkpnt_nxtoid != FirstNormalObjectId)
+ pg_fatal("New cluster is not pristine: OIDs have been assigned since initdb (%u != %u)\n",
+ new_cluster.controldata.chkpnt_nxtoid, FirstNormalObjectId);
On wraparound FirstNormalObjectId would be the first value we use for
nextOid. Okay, that's very unlikely going to happen, still, strictly
speaking, that could be incorrect.
>> I think this would be worth addressing nonetheless, for robustness. For
>> comparison, "cp" and "mv" will error if you give source and destination that
>> are the same file.
> I addressed this in 002.
+ if (strcmp(make_absolute_path(old_cluster.pgdata),
+ make_absolute_path(new_cluster.pgdata)) == 0)
+ pg_fatal("cannot upgrade a cluster on top of itself");
Shouldn't this be done after adjust_data_dir(), which is the point
where we'll know the actual data folders we are working on by querying
postgres -C data_directory?
|Next Message||Masahiko Sawada||2022-12-19 07:13:45||Re: [PoC] Improve dead tuple storage for lazy vacuum|
|Previous Message||Peter Smith||2022-12-19 06:35:14||Re: isolationtester - allow a session specific connection string|