Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> But with a down server, you just force people to do pg_resetxlog, which
> loses both the corruption (probably) and real, useful data (likely) and
> *then* they bring up the server. I don't see why we should force people
> to take a manual action and lose data to bring up the server.
That's all fine, but simply reducing the message level from PANIC to LOG
remains an utterly unacceptable "solution". What will happen is that
the server will start, the DBA will go back to sleep after ignoring
(most likely, never even reading) the log message, and the corruption
will get worse. The potential consequences of corruption in a pg_class
index, for example, are just horrid. Frankly I'd rather "rm -rf $PGDATA"
and force someone to go back to their last backup than let them continue
to run with a database that is known to be broken and the system didn't
do anything more to warn them than emit a LOG message someplace.
(No, I'm not seriously proposing that as a recovery technique. But it's
no more irresponsible than ignoring a corruption condition.)
regards, tom lane
In response to
pgsql-bugs by date
|Next:||From: Bruce Momjian||Date: 2009-01-08 21:53:46|
|Subject: Re: BUG #4509: array_cat's null behaviour is
|Previous:||From: Simon Riggs||Date: 2009-01-08 20:23:44|
|Subject: Re: PANIC: failed to re-find parent key in "100924" forsplit pages 1606/1673|