problem with psql?
We just ran an OS update on an Xserve which runs our PostgreSQL
server, and now it seems that pg_ctl status doesn't report the
correct status.
~ postgres$ pg_ctl status
pg_ctl: neither postmaster nor postgres running
~ postgres$ ps auxw | grep postgres
postgres 491 0.0 -0.1 33156 1160 ?? S 1:09PM
0:00.16 /usr/local/pgsql/bin/postmaster -D /Volumes/DBRAID/pgsql/data
postgres 629 0.0 -0.0 31844 216 ?? S 1:09PM 0:00.27
postgres: logger process
postgres 631 0.0 -0.0 33140 744 ?? S 1:09PM 0:00.06
postgres: writer process
postgres 632 0.0 -0.0 31860 276 ?? S 1:09PM 0:00.02
postgres: archiver process
postgres 633 0.0 -0.0 32864 164 ?? S 1:09PM 0:00.02
postgres: stats buffer process
postgres 634 0.0 -0.0 31888 284 ?? S 1:09PM 0:00.03
postgres: stats collector process
We are able to connect to the instance (using psql), but cannot shut
down or restart the instance using pg_ctl (it just reports that the
server is not running). We are running PostgreSQL version 8.0.0 and
Mac OS X 10.3.9. Can anyone tell us what's going on?
Thanks!
Tim
Timothy Perrigo <tperrigo@wernervas.com> writes:
We are able to connect to the instance (using psql), but cannot shut
down or restart the instance using pg_ctl (it just reports that the
server is not running). We are running PostgreSQL version 8.0.0 and
Mac OS X 10.3.9. Can anyone tell us what's going on?
Sounds to me like you're running pg_ctl with a $PGDATA setting that
doesn't match where the server actually lives. Try
"show data_directory;" in psql to verify what the server thinks $PGDATA
is.
A less likely possibility is that some outside force removed the
$PGDATA/postmaster.pid file. If that's the case, signal the postmaster
to shut down using "kill -TERM" (equivalent of normal shutdown) or "kill
-INT" (equivalent of fast shutdown) and then restart it to recreate the
pid file. ("pg_ctl stop" is actually just a wrapper around these signal
operations...)
regards, tom lane
I've heard from others that OS X's remote desktop equivalent uses an
internal PosgreSQL database in an embedded install that uses the default
PostgreSQL port. That could be the cause of your trouble...
On Mon, Nov 28, 2005 at 01:24:37PM -0600, Timothy Perrigo wrote:
We just ran an OS update on an Xserve which runs our PostgreSQL
server, and now it seems that pg_ctl status doesn't report the
correct status.~ postgres$ pg_ctl status
pg_ctl: neither postmaster nor postgres running~ postgres$ ps auxw | grep postgres
postgres 491 0.0 -0.1 33156 1160 ?? S 1:09PM
0:00.16 /usr/local/pgsql/bin/postmaster -D /Volumes/DBRAID/pgsql/data
postgres 629 0.0 -0.0 31844 216 ?? S 1:09PM 0:00.27
postgres: logger process
postgres 631 0.0 -0.0 33140 744 ?? S 1:09PM 0:00.06
postgres: writer process
postgres 632 0.0 -0.0 31860 276 ?? S 1:09PM 0:00.02
postgres: archiver process
postgres 633 0.0 -0.0 32864 164 ?? S 1:09PM 0:00.02
postgres: stats buffer process
postgres 634 0.0 -0.0 31888 284 ?? S 1:09PM 0:00.03
postgres: stats collector processWe are able to connect to the instance (using psql), but cannot shut
down or restart the instance using pg_ctl (it just reports that the
server is not running). We are running PostgreSQL version 8.0.0 and
Mac OS X 10.3.9. Can anyone tell us what's going on?Thanks!
Tim---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
[Reordering top-posted reply]
On Mon, Nov 28, 2005 at 01:24:37PM -0600, Timothy Perrigo wrote:
We just ran an OS update on an Xserve which runs our PostgreSQL
server, and now it seems that pg_ctl status doesn't report the
correct status.
<snip />
We are able to connect to the instance (using psql), but cannot shut
down or restart the instance using pg_ctl (it just reports that the
server is not running). We are running PostgreSQL version 8.0.0 and
Mac OS X 10.3.9. Can anyone tell us what's going on?
On Nov 29, 2005, at 8:56 , Jim C. Nasby wrote:
I've heard from others that OS X's remote desktop equivalent uses an
internal PosgreSQL database in an embedded install that uses the
default
PostgreSQL port. That could be the cause of your trouble...
Conflicts with the ARD-installed server has been an issue for me on
and off in the past, though I haven't been able to connect to the
server using psql without specifying the ard database, user, and
password. Also, I believe only the ARD server has the embedded
PostgreSQL server (and an old one at that). Do you actually have the
ARD server software installed on the Xserve? (My guess is you may be
using the client software that is installed with the OS.)
Also, could you check who owns those processes? The ARD-installed
server will probably be owned by someone (such as daemon, though I
don't recall off the top of my head) other than your normal postgres
server.
If you find it *is* a problem with ARD (which I am inclined to
doubt), you can alter the port used by the ARD-installed PostgreSQL
server by changing the port it uses in
/var/db/RemoteManagement/RMDB/rmdb.data/postgresql.conf
Hope this helps.
Michael Glaesemann
grzm myrealbox com
(Oops...originally sent this to Jim, instead of the group)
Thanks for the reply...Yes, we do have ARD installed on the machine,
but I believe the postgres instance that we see running (through ps
auxw | grep postgres) is our server instance (pointed at our data
directory), not the ARD instance. We are still able to connect to
our database using psql (and via JDBC). Does this still seem like it
could be an ARD conflict?
On Nov 28, 2005, at 5:56 PM, Jim C. Nasby wrote:
Show quoted text
I've heard from others that OS X's remote desktop equivalent uses an
internal PosgreSQL database in an embedded install that uses the
default
PostgreSQL port. That could be the cause of your trouble...On Mon, Nov 28, 2005 at 01:24:37PM -0600, Timothy Perrigo wrote:
We just ran an OS update on an Xserve which runs our PostgreSQL
server, and now it seems that pg_ctl status doesn't report the
correct status.~ postgres$ pg_ctl status
pg_ctl: neither postmaster nor postgres running~ postgres$ ps auxw | grep postgres
postgres 491 0.0 -0.1 33156 1160 ?? S 1:09PM
0:00.16 /usr/local/pgsql/bin/postmaster -D /Volumes/DBRAID/pgsql/data
postgres 629 0.0 -0.0 31844 216 ?? S 1:09PM 0:00.27
postgres: logger process
postgres 631 0.0 -0.0 33140 744 ?? S 1:09PM 0:00.06
postgres: writer process
postgres 632 0.0 -0.0 31860 276 ?? S 1:09PM 0:00.02
postgres: archiver process
postgres 633 0.0 -0.0 32864 164 ?? S 1:09PM 0:00.02
postgres: stats buffer process
postgres 634 0.0 -0.0 31888 284 ?? S 1:09PM 0:00.03
postgres: stats collector processWe are able to connect to the instance (using psql), but cannot shut
down or restart the instance using pg_ctl (it just reports that the
server is not running). We are running PostgreSQL version 8.0.0 and
Mac OS X 10.3.9. Can anyone tell us what's going on?Thanks!
Tim---------------------------(end of
broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Nov 29, 2005, at 21:55 , Timothy Perrigo wrote:
We are still able to connect to our database using psql (and via
JDBC). Does this still seem like it could be an ARD conflict?
No. I think ARD is blame-free in this instance. Dunno what the issue
is, though. Sorry.
Michael Glaesemann
grzm myrealbox com
On Nov 28, 2005, at 6:14 PM, Michael Glaesemann wrote:
[Reordering top-posted reply]
Conflicts with the ARD-installed server has been an issue for me on
and off in the past, though I haven't been able to connect to the
server using psql without specifying the ard database, user, and
password. Also, I believe only the ARD server has the embedded
PostgreSQL server (and an old one at that). Do you actually have
the ARD server software installed on the Xserve? (My guess is you
may be using the client software that is installed with the OS.)Also, could you check who owns those processes? The ARD-installed
server will probably be owned by someone (such as daemon, though I
don't recall off the top of my head) other than your normal
postgres server.If you find it *is* a problem with ARD (which I am inclined to
doubt), you can alter the port used by the ARD-installed PostgreSQL
server by changing the port it uses in/var/db/RemoteManagement/RMDB/rmdb.data/postgresql.conf
Hope this helps.
Michael Glaesemann
grzm myrealbox com
Thanks for the reply Michael. As I just wrote in response to Jim's
post, I don't think it is an ARD problem. The postmaster instance
running on the machine is our instance, not the ARD instance, and is
pointed at our data directory. We are able to connect to our
database using psql and JDBC; it is just that pg_ctl seems to be
lying to us! I have been suspect of ARD in the past (though at the
moment I can't remember why), but in this case I don't think it is
the source of the problem.
We are going to try updating the machine to PostgreSQL 8.1 tonight; I
will let you all know if that corrects the issue, but I'd really like
to understand what is going on, so if anyone has any ideas, please
let me know!
Thanks,
Tim
Tom,
Thanks for the reply...something did in fact remove the
postmaster.pid file! We will have to look into this further to track
down the culprit.
Thank you everyone for your responses!
Tim
On Nov 28, 2005, at 3:36 PM, Tom Lane wrote:
Show quoted text
Timothy Perrigo <tperrigo@wernervas.com> writes:
We are able to connect to the instance (using psql), but cannot shut
down or restart the instance using pg_ctl (it just reports that the
server is not running). We are running PostgreSQL version 8.0.0 and
Mac OS X 10.3.9. Can anyone tell us what's going on?Sounds to me like you're running pg_ctl with a $PGDATA setting that
doesn't match where the server actually lives. Try
"show data_directory;" in psql to verify what the server thinks
$PGDATA
is.A less likely possibility is that some outside force removed the
$PGDATA/postmaster.pid file. If that's the case, signal the
postmaster
to shut down using "kill -TERM" (equivalent of normal shutdown) or
"kill
-INT" (equivalent of fast shutdown) and then restart it to recreate
the
pid file. ("pg_ctl stop" is actually just a wrapper around these
signal
operations...)regards, tom lane