Re: Improving compressibility of WAL files

* Simon Riggs <simon(at)2ndQuadrant(dot)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(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.