On 2/11/20 9:00 AM, Rich Shepard wrote:
On Tue, 11 Feb 2020, Adrian Klaver wrote:
The above runs the psql client not the server. It is a way of determining
what version binaries /usr/lib64/postgresql/11/bin/ actually contains.
Adrian,
Aha! Running the command taught me a couple of valuable l
On Tue, 11 Feb 2020, Adrian Klaver wrote:
The above runs the psql client not the server. It is a way of determining
what version binaries /usr/lib64/postgresql/11/bin/ actually contains.
Adrian,
Aha! Running the command taught me a couple of valuable lessons because both
11 and 12 show they'r
On 2/11/20 5:43 AM, Rich Shepard wrote:
On Mon, 10 Feb 2020, Adrian Klaver wrote:
So you already have 11 and 12 instances of Postgres running?
Adrian,
No. Both 11 and 12 are installed; neither is running. I have a cron job
that
runs pg_dumpall every weekday night
If so why use pg_upgrade
On Tue, 11 Feb 2020, Rich Shepard wrote:
A final question: which conf file do I edit so when I enter 'psql -l' (or
open a specific database) I don't need to enter my password? I don't
recall having to reset this permission with prior upgrades and want to do
so now.
Never mind: I found it: /var
On Tue, 11 Feb 2020, Rich Shepard wrote:
So you already have 11 and 12 instances of Postgres running?
Adrian,
I just started 12.1 and, as user postgres, read last Friday's backup file.
All's well.
A final question: which conf file do I edit so when I enter 'psql -l' (or
open a specific datab
On Mon, 10 Feb 2020, Adrian Klaver wrote:
So you already have 11 and 12 instances of Postgres running?
Adrian,
No. Both 11 and 12 are installed; neither is running. I have a cron job that
runs pg_dumpall every weekday night.
If so why use pg_upgrade?
Because I wanted to try it rather than
On 2/10/20 4:07 PM, Rich Shepard wrote:
On Mon, 10 Feb 2020, Adrian Klaver wrote:
What it is saying is -b and -d are pointing at binary and data
directories
that are incompatible. You need to make sure that:
/usr/lib64/postgresql/11/bin/
and
/var/lib/pgsql/11/data
are actually pointing at 11
On Mon, 10 Feb 2020, Adrian Klaver wrote:
What it is saying is -b and -d are pointing at binary and data directories
that are incompatible. You need to make sure that:
/usr/lib64/postgresql/11/bin/
and
/var/lib/pgsql/11/data
are actually pointing at 11 instances of binaries and data respective
On 2/10/20 3:40 PM, Rich Shepard wrote:
On Mon, 10 Feb 2020, Rich Shepard wrote:
Good advice; I'll do that.
Huh! Not what I expected:
postgres@salmo:~$ pg_upgrade -c -b /usr/lib64/postgresql/11/bin/ -B
/usr/lib64/postgresql/12/bin/ -d /var/lib/pgsql/11/data -D
/var/lib/pgsql/12/data/
(All o
On Mon, 10 Feb 2020, Rich Shepard wrote:
Good advice; I'll do that.
Huh! Not what I expected:
postgres@salmo:~$ pg_upgrade -c -b /usr/lib64/postgresql/11/bin/ -B
/usr/lib64/postgresql/12/bin/ -d /var/lib/pgsql/11/data -D
/var/lib/pgsql/12/data/
(All on one line; wrapped by alpine.)
Performi
On Mon, 10 Feb 2020, Adrian Klaver wrote:
I don't know that the port numbers are required.
They are not: https://www.postgresql.org/docs/12/pgupgrade.html
"Obviously, no one should be accessing the clusters during the upgrade.
pg_upgrade defaults to running servers on port 50432 to avoid uninte
On 2/10/20 1:59 PM, Rich Shepard wrote:
Running Slackware-14.2/x86_64. Current installation is postgres-11.5 and
I'm
upgrading to postgresql-12.1. Both versions are installed and stopped.
If I have correctly read the pg_upgrade manual page this is the command to
use (as user postgres) with line
On Mon, 10 Feb 2020, Rich Shepard wrote:
-B /usr/lib64/postgesql/12/bin/ \
Typo: it should be /usr/lib64/postgresql/12/bin/
Rich
Running Slackware-14.2/x86_64. Current installation is postgres-11.5 and I'm
upgrading to postgresql-12.1. Both versions are installed and stopped.
If I have correctly read the pg_upgrade manual page this is the command to
use (as user postgres) with lines split to fit the message; the command wi
14 matches
Mail list logo
