Re: database errors - Mailing list pgsql-hackers

From Tom Lane
Subject Re: database errors
Date
Msg-id 2803.1084591873@sss.pgh.pa.us
Whole thread Raw
In response to Re: database errors  (Michael Brusser <michael@synchronicity.com>)
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> On Fri, 2004-05-14 at 02:00, Tom Lane wrote:
>> Okay, you have a page with an LSN of A971020 which is past end of XLOG
>> (5000050).  You may have created this problem for yourself by doing
>> pg_resetxlog with poorly chosen parameters. 

> Is there a way to know exactly what those parameters should be?

Not a very good one.  The thing about pg_resetxlog (which perhaps is
underemphasized in the documentation) is that it is by definition a
wizard's tool: if you need to use it then the software has failed,
and so it would be rather foolish to assume that the software can
give you reliable information about how to use the recovery tool.

Having said that, though, one could certainly imagine some kind of
scanning tool that gives you a better picture of what you have,
for instance statistics about all the page LSNs in the database.
I'd still want some human judgement in the loop, but gathering
raw data is what computers are good at.

If you feel like working on that, be my guest (but please finish
PITR first ;-))

> I was looking at writing an aggregate to allow use of xmax/xmin within a
> max function, then generate some SQL to run against every table.

Um.  Bear in mind that the only time you will want this info is when you
have a nonfunctional database.  Within-SQL tools will not save your
bacon in that situation.  I was thinking of some sort of standalone
tool (think pg_filedump on steroids...)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: relcache refcount
Next
From: Alvaro Herrera
Date:
Subject: Re: relcache refcount