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

Re: 7.1 startup recovery failure

From: "Rod Taylor" <rbt(at)barchord(dot)com>
To: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
Cc: "Hackers List" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 7.1 startup recovery failure
Date: 2001-05-01 03:12:06
Message-ID: 015f01c0d1ec$80734960$2205010a@jester (view raw or flat)
Thread:
Lists: pgsql-hackers
Corrupted or not, after a crash take a snapshot of the data tree
before firing it back up again.  Doesn't take that much time
(especially with a netapp filer) and it allows for a virtually
unlimited number of attempts to solve the trouble or debug.

--
Rod Taylor
   BarChord Entertainment Inc.
----- Original Message -----
From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Vadim Mikheev" <vmikheev(at)sectorbase(dot)com>
Cc: "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Sent: Monday, April 30, 2001 11:02 PM
Subject: Re: [HACKERS] 7.1 startup recovery failure


> Vadim Mikheev wrote:
> >
> > > There's a report of startup recovery failure in Japan.
> > > Redo done but ...
> > > Unfortunately I have no time today.
> >
> > Please ask to start up with wal_debug = 1...
> >
>
> Isn't it very difficult for dbas to leave the
> corrupted database as it is ?
> ISTM we could hardly expect to get the log with
> wal_debug = 1 unless we automatically force the
> log in case of recovery failures.
>
> regards,
> Hiroshi Inoue
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
>


In response to

Responses

pgsql-hackers by date

Next:From: Oleg BartunovDate: 2001-05-01 07:17:05
Subject: Sorry, need to restart postmaster at db.hub.org (fts.postgresql.org)
Previous:From: Hiroshi InoueDate: 2001-05-01 03:02:32
Subject: Re: 7.1 startup recovery failure

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