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.
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.
regards, tom lane
