On Mon, 2004-07-05 at 22:46, Tom Lane wrote:
Simon Riggs <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
