Re: database errors

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: michael(at)synchronicity(dot)com, Pgsql-Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: database errors
Date: 2004-05-15 03:31:13
Message-ID: 2803.1084591873@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2004-05-15 03:45:31 Re: relcache refcount
Previous Message Tom Lane 2004-05-15 03:21:42 Re: relcache refcount