Possible better pg_ctl start/stop handling?

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Possible better pg_ctl start/stop handling?
Date: 2005-07-11 17:06:43
Message-ID: 42D2A723.5060702@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

Interesting problem with pg_ctl. We have ran into this consistently as I
am sure a lot of other people have. If PostgreSQL does not get shutdown
correctly, the postmaster.pid file is still in PGDATA. This of course
causing problems starting up (and it should).

However it seems that pg_ctl if issued a stop should be able to remove
the file. Below is a speicifc example:

bash-3.00$ bin/pg_ctl -D data start
pg_ctl: another postmaster may be running; trying to start postmaster anyway
LOG: could not load root certificate file "root.crt": No such file or
directory
DETAIL: Will not verify client certificates.
FATAL: pre-existing shared memory block (key 5432001, ID 19202077) is
still in use
HINT: If you're sure there are no old server processes still running,
remove the shared memory block with the command "ipcclean", "ipcrm", or
just delete the file "postmaster.pid".
pg_ctl: could not start postmaster
Examine the log output.
bash-3.00$ bin/pg_ctl -D data stop
pg_ctl: could not send stop signal (PID: 10180): No such process
bash-3.00$

As we can see pg_ctl knows that the PID does not exist. If the PID does
not exist is it safe to assume that we can remove the file? So that we
may start again?

Sincerely,

Joshua D. Drake

--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2005-07-11 17:11:34 Re: Hide source code
Previous Message Alvaro Herrera 2005-07-11 17:04:37 Re: fetch_search_path() and elog.c