Is there a TODO here, like "Allow recovery from corrupt pg_control via
WAL"?
---
Kevin Brown wrote:
> Tom Lane wrote:
> > Kevin Brown <[EMAIL PROTECTED]> writes:
> > > One question I have is: in the event of a crash, why not
Is there a TODO here? I like the idea of not writing pg_controldata, or
at least allowing it not to be read, perhaps with a pg_resetxlog flag so
we can cleanly recover from a corrupt pg_controldata if the WAL files
are OK.
We don't want to get rid of the WAL file rename optimization because
thos
Curt Sampson <[EMAIL PROTECTED]> writes:
> On Sat, 25 Jan 2003, Tom Lane wrote:
>> We'd have to take it on faith that we should replay the visible files
>> in their name order.
> Couldn't you could just put timestamp information at the beginning if
> each file,
Good thought --- there's already an
Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > One question I have is: in the event of a crash, why not simply replay
> > all the transactions found in the WAL? Is the startup time of the
> > database that badly affected if pg_control is ignored?
>
> Interesting thought, indeed. S
On Sat, 25 Jan 2003, Tom Lane wrote:
> We'd have to take it on faith that we should replay the visible files
> in their name order.
Couldn't you could just put timestamp information at the beginning if
each file, (or perhaps use that of the first transaction), and read the
beginning of each file
Kevin Brown <[EMAIL PROTECTED]> writes:
> One question I have is: in the event of a crash, why not simply replay
> all the transactions found in the WAL? Is the startup time of the
> database that badly affected if pg_control is ignored?
Interesting thought, indeed. Since we truncate the WAL aft
