On Mon, Jul 25, 2016 at 11:21 PM, Chapman Flack <c...@anastigmatix.net> wrote: > The impression that leaves is of tools that relied too heavily > on internal format knowledge to be viable outside of core, which > have had at least periods of incompatibility with newer PG versions, > and whose current status, if indeed any are current, isn't easy > to find out.
WAL format has gone through a lot of changes in 9.4 as well. 9.3 has as well introduced xlogreader.c which is what *any* client trying to read WAL into an understandable format should use. > And that, I assume, was also the motivation to put the zeroing > in AdvanceXLInsertBuffer, eliminating the need for one narrow, > specialized tool like pg{_clear,_compress,less}log{,tail}, so > the job can be done with ubiquitous, bog standard (and therefore > *very* exhaustively tested) tools like gzip. Exactly, and honestly this has been a huge win to make such segments more compressible. > Even so, it still seems to me that a cheaper solution is a %e > substitution in archive_command: just *tell* the command where > the valid bytes end. Accomplishes the same thing as ~ 16 MB > of otherwise-unnecessary I/O at the time of archiving each > lightly-used segment. > > Then the actual zeroing could be suppressed to save I/O, maybe > with a GUC variable, or maybe just when archive_command is seen > to contain a %e. Commands that don't have a %e continue to work > and compress effectively because of the zeroing. This is over-complicating things for little gain. The new behavior of filling in with zeros the tail of a segment makes things far better when using gzip in archive_command. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers