> > If there is no pg_control or it's corrupted or points to
> > unexistent/corrupted checkpoint record then scan logs from
> > newest to oldest one till we find last valid checkpoint record
> > or oldest valid log record and than redo from there.
>
> And how well will that approach work if the last checkpoint record
> got written near the start of a log segment file, and then the
> checkpointer discarded all your prior log segments because "you don't
> need those anymore"? If the checkpoint record gets corrupted,
> you have no readable log at all.
The question - why should we have it? It is assumed that data files
are flushed before checkpoint appears in log. If this assumtion
is wrong due to *bogus* fsync/disk/whatever why should we increase
disk space requirements which will affect *good* systems too?
What will we buy with extra logs? Just some data we can't
guarantee consistency anyway?
It seems that you want guarantee more than me, Tom -:)
BTW, in some my tests size of on-line logs was ~ 200Mb with default
checkpoint interval. So, it's worth to care about on-line logs size.
> > As I explained in short already: with UNDO we'll be able to reuse
> > XIDs after restart - ie there will be no point to have NEXTXID
> > records at all. And there is no point to add it now.
> > Does it fix anything? Isn't "fixing" all what we must do in beta?
>
> If you really insist, I'll take it out again, but I'm unconvinced
> that that's necessary.
Please convince me that NEXTXID is necessary.
Why add anything that is not useful?
Vadim
