Re: PITR Archive Recovery plus WIP PITR

On Wed, 2004-07-14 at 16:00, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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).

> 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