Re: Why we really need timelines *now* in PITR - Mailing list pgsql-hackers

From Christopher Kings-Lynne
Subject Re: Why we really need timelines *now* in PITR
Date
Msg-id 40FF1D67.5090507@familyhealth.com.au
Whole thread Raw
In response to Re: Why we really need timelines *now* in PITR  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Why we really need timelines *now* in PITR
List pgsql-hackers
> 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: miniscule compiler barf in pg_ctl.c
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: Sorting out acl fixes