Skip site navigation (1) Skip section navigation (2)

Re: UTC4115FATAL: the database system is in recovery mode

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: Mathew Samuel <Mathew(dot)Samuel(at)entrust(dot)com>, "'pgsql-general(at)postgresql(dot)org'" <pgsql-general(at)postgresql(dot)org>
Subject: Re: UTC4115FATAL: the database system is in recovery mode
Date: 2011-05-31 02:14:08
Message-ID: 15009.1306808048@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-general
Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> writes:
> On 05/30/2011 10:29 PM, Mathew Samuel wrote:
>> 2011-03-28 10:44:42 UTC3932ERROR: canceling statement due to statement
>> timeout
>> 2011-03-28 10:44:42 UTC3932STATEMENT: vacuum full analyze _zamboni.sl_log_1
>> 2011-03-28 10:44:42 UTC3932PANIC: cannot abort transaction 1827110275,
>> it was already committed
>> 2011-03-28 10:44:42 UTC3566LOG: server process (PID 3932) was terminated
>> by signal 6

> Interesting. It almost looks like a VACUUM FULL ANALYZE was cancelled by 
> statement_timeout, couldn't be aborted (assuming it was in fact 
> 1827110275) and then the backend crashed with a signal 6 (SIGABRT). 

Yeah, that seems highly likely.  There's a long-known problem in the
pre-9.0 implementation of VACUUM FULL, that it marks itself as committed
well before the vacuuming is actually done.  Any error that occurs after
that point results in exactly the above symptom.  There's a hack
solution for that in releases made after Nov 2009, and getting rid of
the problem in a cleaner fashion was one of the motivations for
replacing the VACUUM FULL implementation in 9.0.  But I suppose the OP
is running something not too up-to-date :-(.

> Wow. Four hours recovery with default checkpoint settings.

Ouch ... the reason for that needs investigation.

			regards, tom lane

In response to

pgsql-general by date

Next:From: Tom LaneDate: 2011-05-31 02:39:48
Subject: Re: [9.1beta1] UTF-8/Regex Word-Character Definition excluding accented letters
Previous:From: David JohnstonDate: 2011-05-31 01:04:24
Subject: [9.1beta1] UTF-8/Regex Word-Character Definition excluding accented letters

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group