Re: Point in Time Recovery - Mailing list pgsql-hackers

From Richard Huxton
Subject Re: Point in Time Recovery
Date
Msg-id 40EAF6E3.9090508@archonet.com
Whole thread Raw
In response to Re: Point in Time Recovery  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Point in Time Recovery  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Simon Riggs wrote:
> On Mon, 2004-07-05 at 22:46, Tom Lane wrote:
> 
>>Simon Riggs <simon@2ndquadrant.com> writes:
>>
>>>Should we use a different datatype than time_t for the commit timestamp,
>>>one that offers more fine grained differentiation between checkpoints?
>>
>>Pretty much everybody supports gettimeofday() (time_t and separate
>>integer microseconds); you might as well use that.  Note that the actual
>>resolution is not necessarily microseconds, and it'd still not be
>>certain that successive commits have distinct timestamps --- so maybe
>>this refinement would be pointless.  You'll still have to design a user
>>interface that allows selection without the assumption of distinct
>>timestamps.
> 
> 
> Well, I agree, though without the desired-for UI now, I think some finer
> grained mechanism would be good. This means extending the xlog commit
> record by a couple of bytes...OK, lets live a little.

At the risk of irritating people, I'll repeat what I suggested a few 
weeks ago...

Add a table: pg_pitr_checkpt (pitr_id SERIAL, pitr_ts timestamptz, 
pitr_comment text)
Let the user insert rows in transactions as desired. Let them stop the 
restore when a specific (pitr_ts,pitr_comment) gets inserted (or on 
pitr_id if they record it).

IMHO time is seldom relevant, event boundaries are.

If you want to add special syntax for this, fine. If not, an INSERT 
statement is a convenient way to do this anyway.

--   Richard Huxton  Archonet Ltd


pgsql-hackers by date:

Previous
From: markw@osdl.org
Date:
Subject: Re: dbt2-pgsql on OSDL
Next
From: David Fetter
Date:
Subject: Re: Error Codes