| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Christian Schröder <cs(at)deriva(dot)de> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: (Never?) Kill Postmaster? |
| Date: | 2007-10-31 23:59:57 |
| Message-ID: | 23274.1193875197@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
=?ISO-8859-1?Q?Christian_Schr=F6der?= <cs(at)deriva(dot)de> writes:
> But then, when I tried to reconnect to the database, I received the
> following message:
> <2007-10-31 22:50:01 CET - chschroe> FATAL: the database system is in
> recovery mode
> Ok, you wrote "Postgres will recover automatically", but could this take
> several minutes?
Yeah, potentially. I don't suppose you have any idea how long it'd been
since your last checkpoint, but what do you have checkpoint_timeout and
checkpoint_segments set to?
> What is the conclusion of this experience?
That you have an itchy trigger finger ;-). It looks from the log that
you needed to wait only a few seconds longer for the recovery to have
completed.
What I'd like to know about is why the child process was unresponsive to
SIGINT in the first place. There's little we can do about long-running
plpython functions, for instance, but if it was looping in Postgres
proper then we should do something about that. Can you reproduce this
problem easily?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sam Mason | 2007-11-01 01:23:18 | Re: Securing stored procedures and triggers |
| Previous Message | Catalin Marinas | 2007-10-31 23:26:47 | Re: Fragments in tsearch2 headline |