Thread: Re: PITR: XLog File compression on Archive

> PS: but something you *could* do in 8.0 is replace "cp" by "gzip" to
> archive compressed files that way.

How about replacing the page image records with a same size dummy record
that only contains a dummy header and all 0's. If the archiver cares about
space he will use some sort of compression anyway.

Andreas

> Re-thinking the whole purpose of the additional full page images appended to
> the xlog records, I now understand and agree with Tom's comment in the docs
> that we don't need to include those additional full page images for PITR -
> they only exist to correctly recover the database in the event of a crash.
> The reason for this is that the base backup provides a full set of blocks on
> which to recover - there is no danger that the backup contains bad blocks,
> as would be the case for crash recovery.

It is correct, that the base backup cannot contain bad blocks (on OS's we know).
But it can contain newer blocks than WAL records would expect.
Will it not matter if e.g. a page split for a btree index is already in the
index file, but a WAL record exists, that references the not yet split page?
I think not, but I am not sure, since normal crash recovery won't see this
situation because of the page images (that can be older than what is on disk).

Also is there not now code, that logs index recreation by only logging
page images ? We would still need those, no ?

Andreas

"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> But it can contain newer blocks than WAL records would expect.
> Will it not matter if e.g. a page split for a btree index is already in the
> index file, but a WAL record exists, that references the not yet split page?

No.  This is not different from the crash-recovery situation: we always
check to see if the update was already applied.
        regards, tom lane