pg_dump
I have a server which has a socket of /var/run/postgresql/.s.PGSQL.5432.
This is set in the .conf file. However, when I try to run a pg_dump it
complains about the server not running on /tmp/.s.PGSQL.5432. Can anyone
explain this behaviour because if I try the -p option to pg_dump or set
the PGPORT env variable it still gives the same report?
Regards
Garry
garry saddington wrote:
I have a server which has a socket of /var/run/postgresql/.s.PGSQL.5432.
This is set in the .conf file. However, when I try to run a pg_dump it
complains about the server not running on /tmp/.s.PGSQL.5432. Can anyone
explain this behaviour because if I try the -p option to pg_dump or set
the PGPORT env variable it still gives the same report?
Could you have two installations of PG - one from source, one packaged?
--
Richard Huxton
Archonet Ltd
Richard Huxton wrote:
garry saddington wrote:
I have a server which has a socket of /var/run/postgresql/.s.PGSQL.5432.
This is set in the .conf file. However, when I try to run a pg_dump it
complains about the server not running on /tmp/.s.PGSQL.5432. Can anyone
explain this behaviour because if I try the -p option to pg_dump or set
the PGPORT env variable it still gives the same report?Could you have two installations of PG - one from source, one packaged?
Oh, and the -p is useful for setting the port, not the directory for
unix-domain sockets. I think you want to have something like:
pg_dump -h /var/run/postgresql
See the manuals for details.
--
Richard Huxton
Archonet Ltd
On Tue, 2006-11-21 at 17:48 +0000, Richard Huxton wrote:
Richard Huxton wrote:
garry saddington wrote:
I have a server which has a socket of /var/run/postgresql/.s.PGSQL.5432.
This is set in the .conf file. However, when I try to run a pg_dump it
complains about the server not running on /tmp/.s.PGSQL.5432. Can anyone
explain this behaviour because if I try the -p option to pg_dump or set
the PGPORT env variable it still gives the same report?Could you have two installations of PG - one from source, one packaged?
Oh, and the -p is useful for setting the port, not the directory for
unix-domain sockets. I think you want to have something like:
pg_dump -h /var/run/postgresql
See the manuals for details.
Thank you, have read the manuals and the -h section says host initially
but if you read on it tells about a leading / - that's why I missed it
first time round -skim reading!.
Perhaps you may be able to me to explain this:
I have a Zope application which speaks to postgres via psycopg. I have
packaged all components together so that the application can be
installed like 'single click' or thereabouts and I have tested it on
several Linux distributions. Usually there are no problems but
occasionally the psycopg connection will default to a different unix
domain socket to the one that is configured in the .conf file. Nothing
changes apart from the OS. Is there a way to make sure that on
installation the same socket is used irrespective of OS?
Kind Regards
Garry
If you're not running a TCP/IP listening instance of the database and only
out of a UNIX Domain Socket, something like the following WILL work:
pg_dump -p yourPortNumber(probably 5432, if you haven't changed the
default) -U yourUserName(postgres, or other...) dbName > dbname.dmp
As an example - I do run my instance on a different port:
pg_dump -p 63318 -U postgres productionDB > productionDB.dmp
This will in fact use the UNIX Domain Socket and will work.
What is the command string you're using? Do you know what port you're
running on? And a valid user? Does the user require a Password for the
db it's trying to dump from?
On Tue, 21 Nov 2006, garry saddington wrote:
On Tue, 2006-11-21 at 17:48 +0000, Richard Huxton wrote:
Richard Huxton wrote:
garry saddington wrote:
I have a server which has a socket of /var/run/postgresql/.s.PGSQL.5432.
This is set in the .conf file. However, when I try to run a pg_dump it
complains about the server not running on /tmp/.s.PGSQL.5432. Can anyone
explain this behaviour because if I try the -p option to pg_dump or set
the PGPORT env variable it still gives the same report?Could you have two installations of PG - one from source, one packaged?
Oh, and the -p is useful for setting the port, not the directory for
unix-domain sockets. I think you want to have something like:
pg_dump -h /var/run/postgresql
See the manuals for details.Thank you, have read the manuals and the -h section says host initially
but if you read on it tells about a leading / - that's why I missed it
first time round -skim reading!.
Perhaps you may be able to me to explain this:
I have a Zope application which speaks to postgres via psycopg. I have
packaged all components together so that the application can be
installed like 'single click' or thereabouts and I have tested it on
several Linux distributions. Usually there are no problems but
occasionally the psycopg connection will default to a different unix
domain socket to the one that is configured in the .conf file. Nothing
changes apart from the OS. Is there a way to make sure that on
installation the same socket is used irrespective of OS?
Kind Regards
Garry---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
--
Louis Gonzales
louis.gonzales@linuxlouis.net
http://www.linuxlouis.net
garry saddington wrote:
pg_dump -h /var/run/postgresql
See the manuals for details.Thank you, have read the manuals and the -h section says host initially
but if you read on it tells about a leading / - that's why I missed it
first time round -skim reading!.
It's not something I've needed myself, so I had to check. The only
difference was, I knew the psql page of the manuals *had* to cover it.
Perhaps you may be able to me to explain this:
I have a Zope application which speaks to postgres via psycopg. I have
packaged all components together so that the application can be
installed like 'single click' or thereabouts and I have tested it on
several Linux distributions. Usually there are no problems but
occasionally the psycopg connection will default to a different unix
domain socket to the one that is configured in the .conf file. Nothing
changes apart from the OS. Is there a way to make sure that on
installation the same socket is used irrespective of OS?
Normally, you'd set the socket directory at ./configure, compile time.
This suggests to me that psycopg is using libpq to actually connect, and
that was compiled with different settings to the server you supply.
Any reason not to use the distro's built-in package manager to fetch
server and client for you?
--
Richard Huxton
Archonet Ltd
On Tue, 2006-11-21 at 19:00 +0000, Richard Huxton wrote:
garry saddington wrote:
pg_dump -h /var/run/postgresql
See the manuals for details.Thank you, have read the manuals and the -h section says host initially
but if you read on it tells about a leading / - that's why I missed it
first time round -skim reading!.It's not something I've needed myself, so I had to check. The only
difference was, I knew the psql page of the manuals *had* to cover it.Perhaps you may be able to me to explain this:
I have a Zope application which speaks to postgres via psycopg. I have
packaged all components together so that the application can be
installed like 'single click' or thereabouts and I have tested it on
several Linux distributions. Usually there are no problems but
occasionally the psycopg connection will default to a different unix
domain socket to the one that is configured in the .conf file. Nothing
changes apart from the OS. Is there a way to make sure that on
installation the same socket is used irrespective of OS?Normally, you'd set the socket directory at ./configure, compile time.
This suggests to me that psycopg is using libpq to actually connect, and
that was compiled with different settings to the server you supply.
Yes, you are correct libpq is being used and this will explain the
different behaviour. However, I now include libpq in the package which
seems to work OK.
Any reason not to use the distro's built-in package manager to fetch
server and client for you?
The application is aimed at teachers and so it needs to be very simple
for them to test its features. Any barriers to this will reduce the take
up.
Kind Regards
Garry
garry saddington wrote:
On Tue, 2006-11-21 at 19:00 +0000, Richard Huxton wrote:
Any reason not to use the distro's built-in package manager to fetch
server and client for you?The application is aimed at teachers and so it needs to be very simple
for them to test its features. Any barriers to this will reduce the take
up.
In that case, it probably is simplest to make sure you supply all your
own libraries.
There's also a live-cd of PostgreSQL somewhere. You might find that
useful if you wanted to build a boot-and-go demo. Or even a vmware
virtual-image.
--
Richard Huxton
Archonet Ltd
On Tue, 2006-11-21 at 20:23 +0000, Richard Huxton wrote:
garry saddington wrote:
On Tue, 2006-11-21 at 19:00 +0000, Richard Huxton wrote:
Any reason not to use the distro's built-in package manager to fetch
server and client for you?The application is aimed at teachers and so it needs to be very simple
for them to test its features. Any barriers to this will reduce the take
up.In that case, it probably is simplest to make sure you supply all your
own libraries.
I am trying to do this but see below.
There's also a live-cd of PostgreSQL somewhere. You might find that
useful if you wanted to build a boot-and-go demo. Or even a vmware
virtual-image.
I am trying to build postgres with a certain socket but I can not find the correct configure directive, any ideas?
Regards
Garry