Back in 2007 (commit a8d539f12498de52453c8113892cbf48cc62478d), we reduced the maximum number of backup blocks per WAL record from 4 to 3, in order to permit addition of an XLR_BKP_REMOVABLE flag bit that purports to show whether it's safe to suppress full-page-image backup blocks in an external WAL-filtering program. I'm having a problem with this now because I don't see any way to get SP-GiST's leaf page splitting operation to touch less than four pages. So I'd like to propose reverting that decision and again allowing a WAL record to touch as many as four pages.
As the above commit message points out, compression of this sort could only be done externally if that external program knew the complete details of every single type of WAL record, so that it could figure out whether any data needed to be extracted from the full-page images and reinserted in the WAL record. I'm not convinced that anybody has written such a thing or will be able to maintain it into the future, as we feel free to whack around the contents of WAL on a regular basis. The commit message claims that such a program would be posted and maintained on pgfoundry, but I couldn't find any trace of it (not that pgfoundry's search tools are very good, but neither "compress", "xlog" or "wal" produces any hits on such a thing). In any case I think the modern theory about this is you should get a filesystem that prevents torn-page writes, and then you can just turn off full_page_writes. Furthermore, what the XLR_BKP_REMOVABLE bit actually reports is just whether a backup operation is in progress, and I think we have now (or easily could) add reporting records to the WAL stream that tell when a backup starts or stops. So external compression would still be possible if it kept a bit more state around. So: is there actually any such compression program out there? Would anybody really cry if this flag went away? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers