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.
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.
--
Justin
