From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alain Bourgeois <alain(dot)bourgeois(at)zetes(dot)com> |
Cc: | "pgsql-docs(at)lists(dot)postgresql(dot)org" <pgsql-docs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_upgrade -c cannot be run if old cluster is running |
Date: | 2024-09-05 15:13:18 |
Message-ID: | 1847617.1725549198@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
Alain Bourgeois <alain(dot)bourgeois(at)zetes(dot)com> writes:
> When the cluster was created, we did initdb /var/lib/pgsql10/data, the storagebox was not available.
> Then storagebox was delivered, we copied data folder to storagebox in /mnt/pgdata/pgdir and changed postgresql.conf. We didn't delete existing datafiles from /var/lib/pgsql10/data (db was empty).
Yeah, after further experimentation I saw that pg_upgrade would fail
in a pretty obvious way unless the supposedly-config-only directory
also contains a full set of subdirectories (base, pg_wal, etc).
We could imagine removing that check for PG_VERSION. I don't think
that the ensuing call of "postgres -C data_directory" would add
anything meaningful to pg_upgrade's runtime. But then you'd see
"Finding the real data directory" every time, indeed twice (for
source and target directories). That seems like it would create
more confusion than is justified.
On the whole I think this is self-inflicted damage. Leaving that
stuff around was just asking for confusion.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-09-05 20:01:05 | Re: DocBook 5.2 |
Previous Message | Alain Bourgeois | 2024-09-05 15:04:34 | RE: pg_upgrade -c cannot be run if old cluster is running |