This changes the behavior of the start and stop actions to exit
successfully if the server was already started or stopped.
This changes the default behavior of the start action: Before, if the
server was already running, it would print a message and succeed. Now,
that situation will result in an error. When running in idempotent
mode, no message is printed and pg_ctl exits successfully.
It was considered to just make the idempotent behavior the default and
only option, but pg_upgrade needs the old behavior.
The simplest way to handle this is just to copy-and-paste the relevant
code block in fork_process.c, so that's what I did. (It's possible that
something more complicated would be useful to packagers who want to work
with either the old or the new API; but at this point the number of such
people is rapidly approaching zero, so let's just get the minimal thing
done.) Update relevant documentation as well.
script.
To do this, have pg_ctl pass down its parent shell's PID in an environment
variable PG_GRANDPARENT_PID, and teach CreateLockFile() to disregard that PID
as a false match if it finds it in postmaster.pid. This allows us to cope
with one level of postgres-owned shell process even with pg_ctl in the way,
so it's just as safe as starting the postmaster directly. You still have to
be careful about how you write the initscript though.
Adjust the comments in contrib/start-scripts/ to not deprecate use of
pg_ctl. Also, fix the ROTATELOGS option in the OSX script, which was
indulging in exactly the sort of unsafe coding that renders this fix
pointless :-(. A pipe inside the "sudo" will probably result in more
than one postgres-owned process hanging around.
must be stale. Tweak example startup scripts to not use pg_ctl but launch
the postmaster directly, thereby ensuring that only the postmaster's direct
parent shell will be a postgres-owned process. In combination these should
fix the longstanding problem of the postmaster sometimes refusing to start
during reboot because it thinks the old lockfile is not stale.
script for Mac OS X. I added calls to utilize the bundled apache
rotatelogs script in the DB startup for log rotation. Also modified
startup parameters file to allow using the "SystemStarter" utility to
start/stop/restart postgres with a rotating log file.
The script credits David Wheeler, 2002. I wrote him a message about
the changes an he suggested I post them here. I explain some of the
changes below.
Not sure how to submit the changes. I have 3 files, "PostgreSQL"
script, "StartupParameters.plist" file, "pg_startupscript.diff" file.
The diff file was run against the original "PostgreSQL" script file.
I'll try attaching them to this message. If they get filtered I can
resend if needed.
Thanks.
Ray A.
------------------------------------
1) Changed the "Provides" parameter in StartupParameters.plist to
"PostgreSQL" from "postgres database" simply for ease of typing. It
seems that the SystemStarter utility uses the "Provides" value if you
want to control the script. This way I did not have to enclose it in
quotes on commandline. The modified StartupParameters.plist is now an
XML document also.
2) For the startup script I added 2 user modifiable variables:
# do you want to rotate the log files, 1=true 0=false
ROTATELOGS=1
# logfile rotate in seconds
ROTATESEC="604800"
I also added a non modifiable variable:
# The apache log rotation utility
LOGUTIL="/usr/sbin/rotatelogs"
I modified the StartService and RestartService functions to execute
the new commands if the user wants log rotation.
Ray Aspeitia
in the year. This version has only the two files required by the Darwin
startup bundle design. Plus the sh script now uses Darwin-standard
functions to start up PostgreSQL, and it checks for the presence of a
variable in /etc/hostconfig, as do other Darwin startup scripts.
I suggest that a new directory be created,
contrib/start-scripts/darwin, and that these two files be put into it.
Folks who want to use the script can read the comments inside it to
figure out how to use it.
David Wheeler
