X-Original-To: pgsql-admin-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 1017F9FB406 for ; Thu, 21 Sep 2006 12:52:09 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 22840-05 for ; Thu, 21 Sep 2006 15:51:56 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey- Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by postgresql.org (Postfix) with ESMTP id 7203D9FB3B7 for ; Thu, 21 Sep 2006 12:51:55 -0300 (ADT) Received: by wr-out-0506.google.com with SMTP id 55so394253wri for ; Thu, 21 Sep 2006 08:51:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=eXnWuLhVlOZBSxFFq/K6n/cqgAjpipiU6x4qn4j0Vo5+oAhvtVRrOCUrX5bcdfTcLhq/5U5Y8gOiIAC/5Kn8haYhjBzPBxKurIR/uOn+I9zXx02XRmuU8ZsySM3MsedmT5isbXTa2bFciKbNscXisY3HlFj+ygHGLftYDHD8WoI= Received: by 10.90.65.11 with SMTP id n11mr7450234aga; Thu, 21 Sep 2006 08:51:55 -0700 (PDT) Received: by 10.90.81.4 with HTTP; Thu, 21 Sep 2006 08:51:55 -0700 (PDT) Message-ID: Date: Thu, 21 Sep 2006 20:51:55 +0500 From: "Shoaib Mir" To: "Mr. Dan" Subject: Re: psql: FATAL: the database system is starting up Cc: pgsql-admin@postgresql.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10243_10411492.1158853915074" References: X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.2 tagged_above=0 required=5 tests=DNS_FROM_RFC_ABUSE, HTML_MESSAGE, SPF_PASS X-Spam-Level: X-Archive-Number: 200609/227 X-Sequence-Number: 23141 ------=_Part_10243_10411492.1158853915074 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Try using the fast shutdown switch with pg_ctl i.e. -mf, that might help. Thanks, -- Shoaib Mir EnterpriseDB (www.enterprisedb.com) On 9/21/06, Mr. Dan wrote: > > Hi, > > We had to kill postmaster, and it's been ugly. The last backup finished > successfully not last night, but the night before. This is 161 GB > database. > How long should I expect this to take before it starts. Developers > are > coming into my office every 5 minutes asking for updates. It's never > taken > this long to come back. We did have an awful lot of transactions last > night. Is the server replaying everything > > fhttp://by116fd.bay116.hotmail.msn.com/cgi-bin/compose?&curmbox=00000000%2d0000%2d0000%2d0000%2d000000000001&a=3b0ef010ec78a7ca825dcdc7953aaf4c22ff15917d66f2ef8a3ddf1fd5dbd659# > Sendrom the last succesful backup? Is it hanging because it can't find > some WAL files that were archived? It's been an hour and a half so far. > Would a reboot help? > > ~DjK > > > > > > ep 21 10:07:05 p postgres[28301]: [2-3] recovery. > Sep 21 10:07:05 p postgres[28301]: [3-1] < % %2006-09-21 10:07:05 EDT>LOG: > checkpoint record is at 14D/69FFBD8 > Sep 21 10:07:05 p postgres[28301]: [4-1] < % %2006-09-21 10:07:05 EDT>LOG: > redo record is at 14D/696AC20; undo record is at 0/0; shutdown FALSE > Sep 21 10:07:05 p postgres[28301]: [5-1] < % %2006-09-21 10:07:05 EDT>LOG: > next transaction ID: 39405490; next OID: 1799955 > Sep 21 10:07:05 p postgres[28301]: [6-1] < % %2006-09-21 10:07:05 EDT>LOG: > next MultiXactId: 5696; next MultiXactOffset: 11694 > Sep 21 10:07:05 p postgres[28301]: [7-1] < % %2006-09-21 10:07:05 EDT>LOG: > database system was not properly shut down; automatic recovery in progress > Sep 21 10:07:05 p postgres[28301]: [8-1] < % %2006-09-21 10:07:05 EDT>LOG: > redo starts at 14D/696AC20 > Sep 21 10:07:20 p postgres[28305]: [2-1] <[unknown] %[unknown] %2006-09-21 > 10:07:20 EDT>LOG: invalid length of startup packet > > > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > ------=_Part_10243_10411492.1158853915074 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Try using the fast shutdown switch with pg_ctl i.e. -mf, that might help.

Thanks,
--
Shoaib Mir
EnterpriseDB (www.enterprisedb.com)

On 9/21/06, Mr. Dan <bitsandbytes88@hotmail.com> wrote:
Hi,

We had to kill postmaster, and it's been ugly.   The last backup finished
successfully not last night, but the night before.  This is 161 GB database.
   How long should I expect this to take before it starts.   Developers are
coming into my office every 5 minutes asking for updates.   It's never taken
this long to come back.  We did have an awful lot of transactions last
night.    Is the server replaying everything
fhttp://by116fd.bay116.hotmail.msn.com/cgi-bin/compose?&curmbox=00000000%2d0000%2d0000%2d0000%2d000000000001&a=3b0ef010ec78a7ca825dcdc7953aaf4c22ff15917d66f2ef8a3ddf1fd5dbd659#
Sendrom the last succesful backup?   Is it hanging because it can't find
some WAL files that were archived?  It's been an hour and a half so far.
Would a reboot help?

~DjK





ep 21 10:07:05 p postgres[28301]: [2-3]  recovery.
Sep 21 10:07:05 p postgres[28301]: [3-1] < % %2006-09-21 10:07:05 EDT>LOG:
checkpoint record is at 14D/69FFBD8
Sep 21 10:07:05 p postgres[28301]: [4-1] < % %2006-09-21 10:07:05 EDT>LOG:
redo record is at 14D/696AC20; undo record is at 0/0; shutdown FALSE
Sep 21 10:07:05 p postgres[28301]: [5-1] < % %2006-09-21 10:07:05 EDT>LOG:
next transaction ID: 39405490; next OID: 1799955
Sep 21 10:07:05 p postgres[28301]: [6-1] < % %2006-09-21 10:07:05 EDT>LOG:
next MultiXactId: 5696; next MultiXactOffset: 11694
Sep 21 10:07:05 p postgres[28301]: [7-1] < % %2006-09-21 10:07:05 EDT>LOG:
database system was not properly shut down; automatic recovery in progress
Sep 21 10:07:05 p postgres[28301]: [8-1] < % %2006-09-21 10:07:05 EDT>LOG:
redo starts at 14D/696AC20
Sep 21 10:07:20 p postgres[28305]: [2-1] <[unknown] %[unknown] %2006-09-21
10:07:20 EDT>LOG:  invalid length of startup packet



---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not
       match




------=_Part_10243_10411492.1158853915074--