Re: Shutting down a warm standby database in 8.2beta3
От | Stephen Harris |
---|---|
Тема | Re: Shutting down a warm standby database in 8.2beta3 |
Дата | |
Msg-id | 20061123181806.GA1625@pugwash.spuddy.org обсуждение исходный текст |
Ответ на | Re: Shutting down a warm standby database in 8.2beta3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Shutting down a warm standby database in 8.2beta3
|
Список | pgsql-hackers |
On Wed, Nov 22, 2006 at 03:03:03PM -0500, Tom Lane wrote: > Stephen Harris <lists@spuddy.org> writes: > > We can see that the sleep process got it! > > /export/home/swharris/rr[37]: 29537 Quit(coredump) > > And my script detects the trigger file > > Wed Nov 22 13:43:51 EST 2006: End of recovery trigger file found > > > Now database recovery appears to continue as normal; the postgres > > recovery processes are still running, despite having received SIGQUIT > > Well, sure, because system() will have ignored the SIGQUIT. You have to > make the shell script return an abort code rather than exit(1) or > whatever it's doing in this case. (I've tested that CVS HEAD does the Hmm, on Linux I did a kill -QUIT on the process group and then rather than cleanly exiting my recovery script I "kill -9"d it. The database still completed recovery as previously described. > right thing when the script is just a straight invocation of cp. But > if the script is trapping errors, it's going to have to cooperate.) The script doesn't trap errors; ksh itself plays with SIGQUIT. I guess I should rewrite my script in perl and see what happens. -- rgds Stephen
В списке pgsql-hackers по дате отправления: