Re: PITR Phase 2 - Design Planning
От | Simon Riggs |
---|---|
Тема | Re: PITR Phase 2 - Design Planning |
Дата | |
Msg-id | 1083168202.3018.394.camel@stromboli обсуждение исходный текст |
Ответ на | Re: PITR Phase 2 - Design Planning (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: PITR Phase 2 - Design Planning
|
Список | pgsql-hackers |
On Wed, 2004-04-28 at 05:00, Bruce Momjian wrote: > Simon Riggs wrote: > > On Tue, 2004-04-27 at 21:56, Rod Taylor wrote: > > > > Overall, I'd refer back to the points Bruce raised - you certainly do > > > > need a way of finding out the time to recover to, and as others have > > > > said also, time isn't the only desirable "recovery point". > > > > > > Wouldn't it be sufficient to simply use the transaction ID and ensure > > > that all the parameters the user might want to use to find that ID can > > > be made available in the log files? > > > > > > > Yes, of course, all methods of locating a particular xlog file to stop > > at are effectively equivalent. The discussion is mostly about what is > > convenient for the user in a real recovery situation. > > > > >From all that has been said so far, I would implement: > > > > 1. Recovery to a specific txnid, which is fairly straightforward > > 2. Recovery to a specific date/time > > a) either by implementing a log inspection tool that shows the txnid for > > a PIT > > b) implementing recovery to a PIT directly > > 3. Recovery to a named checkpoint > > What if we added transaction id to log_line_prefix? The user could then > log all queries and find the xid where they want to stop, but of course > that assumes they have enabled such logging, and they have access to the > logs. Good thinking. I'll have a look at this and come back to you. Best Regards, Simon Riggs
В списке pgsql-hackers по дате отправления: