On Mon, Apr 09, 2012 at 03:37:09PM -0300, Alvaro Herrera wrote:
>
> Excerpts from Bruce Momjian's message of lun abr 09 15:13:10 -0300 2012:
> > On Mon, Apr 09, 2012 at 10:10:34AM -0400, Robert Haas wrote:
>
> > > This complaint appears to be accurate. I think we should go ahead and
> > > remove that mention.
> >
> > Agreed; removed with the attached patch. I didn't bother keeping the
> > gzip mention because I assume there is little value to using without
> > pglesslog.
>
> I'm not sure that assumption holds. I think you're thinking of the hack
> that zeroes out the "empty" holes in the middle of data pages; those
> didn't compress well unless zeroed out before compression. This tool is
> not about that, but rather about removing redundant info from WAL files.
> It seems to me that WAL files would be as gzip-compressible regardless
> of pglesslog being applied. (Another related tool is clearxlogtail
OK, docs updated with the attached patch.
> which zeroes areas from WAL files when they are empty because of an
> early switch due to archive timeout).
Should we document that?
> The funny thing is, apparently pg_lesslog was intentionally broken by
> changing XLR_BKP_REMOVABLE to XLP_BKP_REMOVABLE (different semantics?)
> and the fixes to make it compile again look simple. It's a bit strange
> that NTT stopped maintaining the tool .. Maybe it wasn't useful anymore?
No idea.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
