Re: Point in Time Recovery
От | Richard Huxton |
---|---|
Тема | Re: Point in Time Recovery |
Дата | |
Msg-id | 40EAF6E3.9090508@archonet.com обсуждение исходный текст |
Ответ на | Re: Point in Time Recovery (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Point in Time Recovery
|
Список | 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 по дате отправления: