Re: Postgresql goes down need to restart (redhat postgresql service script) lock files removal avoid 2 postmasters
От | mlaks |
---|---|
Тема | Re: Postgresql goes down need to restart (redhat postgresql service script) lock files removal avoid 2 postmasters |
Дата | |
Msg-id | 200305081439.08973.mlaks@bellatlantic.net обсуждение исходный текст |
Ответ на | Re: Postgresql goes down need to restart (redhat postgresql service script) lock files removal avoid 2 postmasters (Bruno Wolff III <bruno@wolff.to>) |
Ответы |
Re: Postgresql goes down need to restart (redhat postgresql service script) lock files removal avoid 2 postmasters
|
Список | pgsql-admin |
Bruno, Thanks for your help. I was wondering: Should we in fact be execing the postmaster as you describe or perhaps pg_ctl as Lamar's script uses or perhaps a "new" script that incorporates pg_ctl or postmaster and a signal catching mechanism. The reason I ask is that the way that daemontools stops a service - if you want it to - is via the command svc opts postgresl : with opts -d: Down. If the service is running, send it a TERM signal and then a CONT signal. After it stops, do not restart it. -o: Once. If the service is not running, start it. Do not restart it if it stops. -p: Pause. Send the service a STOP signal. -c: Continue. Send the service a CONT signal. -h: Hangup. Send the service a HUP signal. -a: Alarm. Send the service an ALRM signal. -i: Interrupt. Send the service an INT signal. -t: Terminate. Send the service a TERM signal. -k: Kill. Send the service a KILL signal. now we would not want to kill the postmaster, of course. But should we even be TERM'ing the postmaster? I dont know. What do the Postgresql Gurus say? Moreover, if we agree that we need to imbed pg_ctl or postmaster in a script to handle the above things, it should be doable to handle all of the assorted other files if they are neccesary to handle . Do you agree? Also what would be the problem in checking for the existence of a postmaster and if none exists then killing the lock files. My main problem is that I have machines that get creamed by power surges, and then wont restart postgresql on reboot of the system because of the damn lock files. I really want to deal with them up front! MOreover can you tell me more about what init uses the locks for? what is the role of the files /var/run/postmaster.pid /var/lock/subsys/postgresql that Lamar carefully adds and subtracts? rm -f /var/run/postmaster.pid rm -f /var/lock/subsys/postgresql Thanks Mitchell On Thursday 08 May 2003 02:40 pm, you wrote: > On Thu, May 08, 2003 at 14:10:52 -0400, > > mlaks <mlaks@bellatlantic.net> wrote: > > Thank you for your response Bruno. I agree about the importance of using > > the lines > > > > #!/bin/sh > > exec 2>&1 > > exec setuidgid postgres /usr/local/pgsql/bin/postmaster -D > > /usr/local/pgsql/data > > > > in the run file. However, what else must we put in as well? > > > > My question is to understand the lock files for postgresql so I can deal > > with the following: > > Some of the lock files have to do with the init system. Those can be > ignored. Postgres also keeps a lock file and that is used to prevent > two postmasters from running at the same time. You probably don't want > to have a script remove that lock file, because if there really is > another postmaster running, starting a second one can be a disaster. > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
В списке pgsql-admin по дате отправления: