On Wed, 14 Nov 2018, Rich Shepard wrote:
I think that I FUBARed the upgrade from 10.3 to 11.1. I've removed both
packages and am rebuilding 11.1. I'll install it, run initdb on it, then
re-run pg_dumpall on the 10.5 data directory on the old desktop. Starting
from scratch on this new desktop
On Wed, 14 Nov 2018, Tom Lane wrote:
Perhaps those are associated with some other data directory?
Tom/Adrian,
I think that I FUBARed the upgrade from 10.3 to 11.1. I've removed both
packages and am rebuilding 11.1. I'll install it, run initdb on it, then
re-run pg_dumpall on the 10.5 data
Rich Shepard writes:
>ps ax | grep postgres
> shows a number of processes, but psql tells me there's no server running,
> and there is no postmaster.opts or postmaster.pid in the data directory.
Perhaps those are associated with some other data directory?
You could try using lsof on one of
On 11/14/18 6:58 AM, Rich Shepard wrote:
On Tue, 13 Nov 2018, Adrian Klaver wrote:
Just realized the question I should have asked is:
How did you get the pg_dumpall file processed by Postgres?
In other words how did you do it without a password?
As user postgres I entered the command
$
On Tue, 13 Nov 2018, Adrian Klaver wrote:
Just realized the question I should have asked is:
How did you get the pg_dumpall file processed by Postgres?
In other words how did you do it without a password?
As user postgres I entered the command
$ psql -f dump-all.sql
In any case, I need
On 11/13/18 3:47 PM, Rich Shepard wrote:
On Sun, 11 Nov 2018, Rich Shepard wrote:
Looks like the pg_dumpall '-h' option will act on the other host's data
directory.
Worked as advertised. Just read the dumped file into the new 11.1 data
directory.
Just realized the question I should have
On 11/13/18 4:41 PM, Rich Shepard wrote:
On Tue, 13 Nov 2018, Adrian Klaver wrote:
No:
" Each of the first four fields can be a literal value, or *, which
matches anything. "
Adrian,
Okay.
If the record starts with local then that is for socket connections.
If you are connecting to a
On Tue, 13 Nov 2018, Adrian Klaver wrote:
No:
" Each of the first four fields can be a literal value, or *, which matches
anything. "
Adrian,
Okay.
If the record starts with local then that is for socket connections.
If you are connecting to a host e.g -h localhost then you need to look
On 11/13/18 4:24 PM, Rich Shepard wrote:
On Tue, 13 Nov 2018, Adrian Klaver wrote:
You have two options:
1) The preferred one. Keep the password and create a .pgpass file to
hold the password:
https://www.postgresql.org/docs/10/libpq-pgpass.html
Adrian,
That's database-specific if I
On Tue, 13 Nov 2018, Adrian Klaver wrote:
You have two options:
1) The preferred one. Keep the password and create a .pgpass file to hold the
password:
https://www.postgresql.org/docs/10/libpq-pgpass.html
Adrian,
That's database-specific if I read the manual page correctly.
My guess
On 11/13/18 3:47 PM, Rich Shepard wrote:
On Sun, 11 Nov 2018, Rich Shepard wrote:
Looks like the pg_dumpall '-h' option will act on the other host's data
directory.
Worked as advertised. Just read the dumped file into the new 11.1 data
directory.
The new installation is asking for my
On Sun, 11 Nov 2018, Rich Shepard wrote:
Looks like the pg_dumpall '-h' option will act on the other host's data
directory.
Worked as advertised. Just read the dumped file into the new 11.1 data
directory.
The new installation is asking for my password to access my databases.
Where do I
On 11/12/2018 07:55 AM, Rich Shepard wrote:
On Sun, 11 Nov 2018, Ron wrote:
Unless your db is small, do a parallel dump. Even then, do a "-Fc" backup
instead. That's been the recommended method for many years.
Ron,
I've several databases, none 'large.' When I've used pg_dumpall in the
On Sun, 11 Nov 2018, Ron wrote:
Unless your db is small, do a parallel dump. Even then, do a "-Fc" backup
instead. That's been the recommended method for many years.
Ron,
I've several databases, none 'large.' When I've used pg_dumpall in the
past it's always with the clean option (-c) and
On 11/11/2018 02:51 PM, Rich Shepard wrote:
On Sun, 11 Nov 2018, Adrian Klaver wrote:
pg_dumpall is going to need to run against a Postgres server not just a
data directory.
Adrian,
Of course. Yet it's the data directory that's written to the .sql file.
Unless your db is small, do a
On 11/11/18 12:53 PM, Rich Shepard wrote:
On Sun, 11 Nov 2018, Rich Shepard wrote:
Haven't tried to run an application on one host using data on another
host. I'll look at which tool will do that.
Looks like the pg_dumpall '-h' option will act on the other host's data
directory.
No it
On 11/11/18 12:51 PM, Rich Shepard wrote:
On Sun, 11 Nov 2018, Adrian Klaver wrote:
pg_dumpall is going to need to run against a Postgres server not just
a data directory.
Adrian,
Of course. Yet it's the data directory that's written to the .sql file.
In order for pg_dumpall to access
On Sun, 11 Nov 2018, Rich Shepard wrote:
Haven't tried to run an application on one host using data on another
host. I'll look at which tool will do that.
Looks like the pg_dumpall '-h' option will act on the other host's data
directory.
Regards,
Rich
On Sun, 11 Nov 2018, Adrian Klaver wrote:
pg_dumpall is going to need to run against a Postgres server not just a data
directory.
Adrian,
Of course. Yet it's the data directory that's written to the .sql file.
If both your old and new machines are on the same network, why not just
point
On Sun, 11 Nov 2018, Andrew Gierth wrote:
The most reliable and preferred procedure is to use the _new_ version's
pg_dumpall, for example by allowing access to the old host from the new
one (possibly using an ssh port forward), or (on OSes that make it easy to
do package installs of multiple
On 11/11/18 12:18 PM, Rich Shepard wrote:
On Sun, 11 Nov 2018, Andrew Gierth wrote:
The most reliable and preferred procedure is to use the _new_ version's
pg_dumpall, for example by allowing access to the old host from the new
one (possibly using an ssh port forward), or (on OSes that make it
On Sun, 11 Nov 2018, Adrian Klaver wrote:
Not sure if you have any extensions or not, but the part I often skip is
installing extensions in the new cluster before running the dump restore.
Thanks, Adrian. No extensions here.
Regards,
Rich
On 11/11/18 11:21 AM, Rich Shepard wrote:
My current desktop server/workstation is running version 10.5. I'm
configuring a replacement desktop and have installed version 11.1 on it. To
copy all databases from the 10.5 version to the 11.1 version I assume
that I
should do a pg_dumpall on the
> "Rich" == Rich Shepard writes:
Rich> My current desktop server/workstation is running version 10.5.
Rich> I'm configuring a replacement desktop and have installed version
Rich> 11.1 on it. To copy all databases from the 10.5 version to the
Rich> 11.1 version I assume that I should do a
My current desktop server/workstation is running version 10.5. I'm
configuring a replacement desktop and have installed version 11.1 on it. To
copy all databases from the 10.5 version to the 11.1 version I assume that I
should do a pg_dumpall on the current host and read in that file on the
25 matches
Mail list logo
