Re: pg_upgrade allows itself to be run twice

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
Date: 2022-12-19 06:53:14
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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?

In response to

Browse pgsql-hackers by date

  From Date Subject
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