dbTalk Databases Forums  

Re: PITR Archive Recovery plus WIP PITR

comp.databases.postgresql.patches comp.databases.postgresql.patches


Discuss Re: PITR Archive Recovery plus WIP PITR in the comp.databases.postgresql.patches forum.



Reply
 
Thread Tools Display Modes
  #11  
Old   
Simon Riggs
 
Posts: n/a

Default Re: PITR Archive Recovery plus WIP PITR - 07-14-2004 , 06:00 PM






On Wed, 2004-07-14 at 16:00, Tom Lane wrote:
Quote:
Bruce Momjian <pgman (AT) candle (DOT) pha.pa.us> writes:
Tom Lane wrote:
I think it's really important to get this right the first time, both for
reliability's sake and because we are expecting people to write their
own archiving scripts. If we change the xlog segment naming convention
later on, then we will break all those scripts.

We don't have anything hardcoded based on those file names, at last in
PostgreSQL.

Well, I think we do. There's two places where the filename format and
length matters and there are numerous calls to calculate filenames from
log,seg pairs. ...and much of the current patch would need reworking
thoroughly to make sure all differences were changed.

Which is why I was striving for a solution that retained the filename
make-up, by adding a very large number to the log value (we just aren't
gonna run out...I did the math in another post).

Quote:
That's because we've punted the whole problem of archive-segment
management off to the users.

If we did implement this functionality ourselves then I'd be less
worried, since we'd know that future changes would affect only our
own code. But as things stand, we will have very unhappy PITR users
if we change the naming convention later.

Yes, if we are going to change the xlog filename format, we must do it
now. The change must be in effect whether or not you use archive_mode.

....Is there agreement with my previous posts on this....marked "Point in
Time Recovery" over the last few days?
Is that what we should implement?

Overall, the timeline concept is only worth implementing if:
- we archive xlogs
- we recover them
- we recover them to a point in time/txnid

We agreed that the last part wasn't the priority for beta freeze. I'm
willing to spend more time on the timeline idea as long as I've got some
idea that we will be committing what has been developed so far. It takes
effort to keep the patch viable against changes because new commits
update the catalog version, which invalidates all my test databases, as
well as any changes I have to track down. ...and I've been doing that
for a month now - getting much better though, thanks.

If we can review what we have now, I would be most pleased. Until we
commit at least some of it, I'm the only developer and I would like to
open this up to allow others to contribute more easily.

Best Regards, Simon Riggs



---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend



Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.