Re: Shutting down a warm standby database in 8.2beta3

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

In response to

Responses

Browse pgsql-general by date

  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)

Browse pgsql-hackers by date

  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