Hello,
> I need PostgreSQL9.3 which fixed this problem.
>
> It didn't happen in PostgreSQL9.2, so I agree
> with your proposal which changes are done
> against 93_STABLE and master.
>
> Can you fix this in next release(9.3.3)?
I was going to push to move this a bit, but...
> >>> Wouldn't it be better to not archive the old segment, and instead
> >>> switch
> >>> to a new segment after writing the end-of-recovery checkpoint, so that
> >>> the segment on the new timeline is archived sooner?
> >>
> >> It would be better to zero-fill and switch segments, yes. We should
> >> NEVER be in a position of archiving two different versions of the same
> >> segment.
> >
> > Ok, I think we're in agreement that that's the way to go for master.
I've almost inclined to that but on some thoughts on the idea,
comming to think of recovery upto target timeline, the old
segment found to be necessary for the case. Without the old
segment, we would be obliged to seek to the first segment of the
*next* timeline (Is there any (simple) means to predict where is
it?) to complete the task. Is it the right way we kick the older
one out of archive?
> > Now, what to do about back-branches? On one hand, I'd like to apply
> > the same fix to all stable branches, as the current behavior is silly
> > and always has been. On the other hand, we haven't heard any
> > complaints about it, so we probably shouldn't fix what ain't
> > broken. Perhaps we should apply it to 9.3, as that's where we have the
> > acute problem the OP reported. Thoughts?
> >
> > In summary, I propose that we change master and REL9_3_STABLE to not
> > archive the partial segment from previous timeline. Older branches
> > will keep the current behavior.
--
Kyotaro Horiguchi
NTT Open Source Software Center
