From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Harris <lists(at)spuddy(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Shutting down a warm standby database in 8.2beta3 |
Date: | 2006-11-22 20:03:03 |
Message-ID: | 3741.1164225783@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Stephen Harris <lists(at)spuddy(dot)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
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.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-11-22 20:42:47 | Re: MSSQL to PostgreSQL : Encoding problem |
Previous Message | John D. Burger | 2006-11-22 19:51:59 | Re: advanced index (descending and table-presorted descending) |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-11-22 20:10:33 | Re: [BUGS] Out of memory error causes Abort, Abort tries to allocate memory |
Previous Message | Markus Schiltknecht | 2006-11-22 19:58:32 | Re: Integrating Replication into Core |