Tom Lane wrote:
>
> Patrick Macdonald <patrickm@redhat.com> writes:
> > I understand your solution is for the existing architecture which does
> > not support point-in-time recovery. If this item is picked up, your
> > solution will become a stumbling block due the above mentioned log
> > extent deletions.
>
> Hmm, I don't see why it's a stumbling block. There is a notion in the
> present code that log segments might be moved someplace else for
> archiving (rather than just be deleted), and I wasn't planning on
> eliminating that option. I think however that a realistic archival
> mechanism would not simply keep the log segments verbatim. It could
> drop the page images, for a huge space savings, and perhaps also
> eliminate records from aborted transactions. So in reality one could
> still expect to recycle the log segments, just with a somewhat longer
> cycle time --- ie, after the archiver is done copying a segment, then
> you rename it into place as a forward file.
Well, notion and actual practice can be mutually exclusive. Your
initial message stated that you would like to rename the log segment.
This insinuated that the log segment was not moved. Therefore, a
straight rename would cause problems with the future point-in-time
recovery item (ie. the only existing version of log segment N has
been renamed to N+5). A backup of the database could not roll forward
through this name change as stated. That was my objection.
> In any case, a two-or-three-line change is hardly likely to create much
> of an obstacle to PIT recovery, compared to some of the more fundamental
> aspects of the existing WAL design (like its need to start from a
> complete physical copy of the database files). So I'm not sure why
> you're objecting on these grounds.
Hmmm, stating that it is less of a problem than others doesn't make
it the right thing to do. If the two or three lines you mention renames
a segment I want to roll forward through, that's a problem. Yeah, I
know it's not a problem now but it'll have to be changed when PIT comes
into play.
You didn't comment on the idea of two logging methods... circular and
recoverable. Any thoughts?
Cheers,
Patrick