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?
--
Michael
signature.asc
Description: PGP signature
