From: Tom Lane <tgl@sss.pgh.pa.us>
To: Holger Jakobs <holger@jakobs.com>
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: pg_upgrade from 17.10 to 18.4 on Ubuntu fails: Finding the real
 data directory for the target cluster sh: 1: (null)/postgres: not found
In-reply-to: <f5bb021f-8f45-4825-9b4a-39241ea27a2f@jakobs.com>
References: <f5bb021f-8f45-4825-9b4a-39241ea27a2f@jakobs.com>
Comments: In-reply-to Holger Jakobs <holger@jakobs.com>
	message dated "Wed, 12 Aug 2026 12:50:57 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <2642394.1786547656.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Wed, 12 Aug 2026 11:14:16 -0400
Message-ID: <2642395.1786547656@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2642395.1786547656%40sss.pgh.pa.us>
Precedence: bulk

[ redirecting to pgsql-bugs ]

Holger Jakobs <holger@jakobs.com> writes:
> Dear Friends,
> Today a pg_upgrade failed with this awkward message:

> Finding the real data directory for the source cluster        ok
> Finding the real data directory for the target cluster        sh: 1: 
> (null)/postgres: not found

I can reproduce this if (1) I omit -B (and don't give PGBINNEW
either), and (2) the target -D directory is a config-only directory,
that is it contains postgresql.conf but not PG_VERSION.  Given (1),
pg_upgrade is supposed to assume that -B should be the directory
that it itself was executed from.  However, that is filled in by
setup(), which does not run till after adjust_data_dir(), which is
reaching the "Finding the real data directory" bit because of (2).
So we arrive there with cluster->bindir still NULL, and kaboom.

So the temporary workaround for Holger is to specify -B explicitly,
but somebody needs to rethink the order of initialization steps here.
Maybe just move that bit of setup() into parseCommandLine()?

It looks like this is an error of pretty long standing...

			regards, tom lane