Re: Why we really need timelines *now* in PITR

> That gives us enough to talk through and begin some testing.
>
> Anybody have any other horror stories, bring 'em on.

I think that the PITR docs will have to be written in two sections. One
will need to be a pure reference that orthogonally describes the
options, etc. The other section will need to be a scenario-based
explanation of what to do/how to recover in all the major different
failure patterns. It's the only way people (I!) will understand it all.

From my point of view, what I need PITR to be able to do is allow me to
restore to any point in the 24 hour period between pg_dumpalls. I also
need to know what the exact criteria for deleting archived logs every 24
hours, and how that can be determined automatically in a script
(checking the pg_dumpall end-of-log marker exists as well). I need to
be told to copy, not move the logs. Also, I need to be sure that
pg_dumpall is enough, and I don't need to make sure I issue a checkpoint
before the pg_dumpall or anything.

Chris