I really appreciate for the modification.
I also believe XLOG_NOOP is cool to maintains XLOG format consistent.
I'll continue to write a code to produce incremental log record from
the full page writes as well as too maintain CRC, XLOOG_NOOP and
other XLOG locations, I also found that you've added information on
btree strip log records, which anables to produce corresponding
incremental logs from the full page writes.
2007/5/21, Tom Lane <tgl@sss.pgh.pa.us>:
> Koichi Suzuki <suzuki.koichi@oss.ntt.co.jp> writes:
> > As replied to "Patch queue triage" by Tom, here's simplified patch to
> > mark WAL record as "compressable", with no increase in WAL itself.
> > Compression/decompression commands will be posted separately to PG
> > Foundary for further review.
>
> Applied with some minor modifications. I didn't like the idea of
> suppressing the sanity-check on WAL record length; I think that's
> fairly important. Instead, I added a provision for an XLOG_NOOP
> WAL record type that can be used to fill in the extra space.
> The way I envision that working is that the compressor removes
> backup blocks and converts each compressible WAL record to have the
> same contents and length it would've had if written without backup
> blocks. Then, it inserts an XLOG_NOOP record with length set to
> indicate the amount of extra space that needs to be chewed up --
> but in the compressed version of the WAL file, XLOG_NOOP's "data
> area" is not actually stored. The decompressor need only scan
> the file looking for XLOG_NOOP and insert the requisite number of
> zero bytes (and maybe recompute the XLOG_NOOP's CRC, depending on
> whether you want it to be valid for the short-format record in the
> compressed file). There will also be some games to be played for
> WAL page boundaries, but you had to do that anyway.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
--
------
Koichi Suzuki
