Re: Improving compressibility of WAL files

* Simon Riggs <simon@2ndQuadrant.com> [090109 11:33]:
> The patch as stands is IMHO not acceptable because the work to zero the
> file is performed by the unlucky backend that hits EOF on the current
> WAL file, which is bad enough, but it is also performed while holding
> WALWriteLock. 

Agreed, but noting that that extra zero work is contitional on the
"force_swich", meaning that commits backup behind that WALWriteLock only
during forced xlog switches (like archive_timeout and pg_backup).  I
actually did look through verify that when I made the patch, although I
claim that verification to be something anybody else should beleive ;-)
But my given output when I showd the stats/lines/etc did demonstrate
that.

> I like Greg Smith's analysis of this and his conclusion that we could
> provide a %l option, but even that would require work to have that info
> passed to the archiver. Perhaps inside the notification file which is
> already written and read by the write processes. But whether that can or
> should be done for this release is a different debate.

It's certainly not already in this commitfest, just like this patch.  I
thought the initial reaction after I posted it made it pretty clear it
wasn't something people (other than a few of us) were willing to
allow...

a.
-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.