Re: Decreasing WAL size effects

Tom Lane wrote:
> Greg Smith <gsmith(at)gregsmith(dot)com> writes:
> > That pushes the problem of writing a little chunk of code that reads only
> > the right amount of data and doesn't bother compressing the rest onto the
> > person writing the archive command. Seems to me that leads back towards
> > wanting to bundle a contrib module with a good implementation of that with
> > the software. The whole tail clearing bit is in the same situation
> > pg_standby was circa 8.2: the software is available, and it works, but it
> > seems kind of sketchy to those not familiar with the source of the code.
> > Bundling it into the software as a contrib module just makes that problem
> > go away for end-users.
>
> The real reason not to put that functionality into core (or even
> contrib) is that it's a stopgap kluge. What the people who want this
> functionality *really* want is continuous (streaming) log-shipping, not
> WAL-segment-at-a-time shipping. Putting functionality like that into
> core is infinitely more interesting than putting band-aids on a
> segmented approach.

Well, I realize we want streaming archive logs, but there are still
going to be people who are archiving for point-in-time recovery, and I
assume a good number of them are going to compress their WAL files to
save space, because they have to store a lot of them. Wouldn't zeroing
out the trailing byte of WAL still help those people?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +