Re: pg_upgrade allows itself to be run twice

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, 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-01 09:30:16
Message-ID: 36b9d49a-252f-3005-3413-24599bbfbde7@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01.11.22 14:07, Justin Pryzby wrote:
> On Tue, Nov 01, 2022 at 01:54:35PM +0100, Peter Eisentraut wrote:
>> On 07.07.22 08:22, Justin Pryzby wrote:
>>>> This one comes from NextOID in the control data file after a fresh
>>>> initdb, and GetNewObjectId() would enforce that in a postmaster
>>>> environment to be FirstNormalObjectId when assigning the first user
>>>> OID. Would you imply an extra step at the end of initdb to update the
>>>> control data file of the new cluster to reflect FirstNormalObjectId?
>>> I added a call to reset xlog, similar to what's in pg_upgrade.
>>> Unfortunately, I don't see an easy way to silence it.
>>
>> I think it would be better to update the control file directly instead of
>> going through pg_resetwal. (See src/include/common/controldata_utils.h for
>> the required functions.)
>>
>> However, I don't know whether we need to add special provisions that guard
>> against people using postgres --single in complicated ways. Many consider
>> the single-user mode deprecated outside of initdb use.
>
> Thanks for looking.

I think the above is a "returned with feedback" at this point.

> One other thing I noticed (by accident!) is that pg_upgrade doesn't
> prevent itself from trying to upgrade a cluster on top of itself:
>
> | $ /usr/pgsql-15/bin/initdb -D pg15.dat -N
> | $ /usr/pgsql-15/bin/pg_upgrade -D pg15.dat -d pg15.dat -b /usr/pgsql-15/bin
> | Performing Upgrade
> | ------------------
> | Analyzing all rows in the new cluster ok
> | Freezing all rows in the new cluster ok
> | Deleting files from new pg_xact ok
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> | Copying old pg_xact to new server
> | *failure*
> |
> | Consult the last few lines of "pg15.dat/pg_upgrade_output.d/20221101T055916.486/log/pg_upgrade_utility.log" for
>>>
> | command: cp -Rf "pg15.dat/pg_xact" "pg15.dat/pg_xact" >> "pg15.dat/pg_upgrade_output.d/20221101T055916.486/log/pg_upgrade_utility.log" 2>&1
> | cp: cannot stat 'pg15.dat/pg_xact': No such file or directory
>
> This may be of little concern since it's upgrading a version to itself, which
> only applies to developers.

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2022-12-01 09:55:12 Re: Improve performance of pg_strtointNN functions
Previous Message Peter Eisentraut 2022-12-01 09:20:34 Re: [DOCS] Stats views and functions not in order?