Re: PITR: XLog File compression on Archive

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PITR: XLog File compression on Archive
Date: 2004-08-23 22:55:30
Message-ID: 20810.1093301730@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> As a result, I have thought that there may be a way to remove those pages
> from the xlog files immediately before being copied away to archive, without
> effecting crash recovery logic AT ALL.

This isn't all that easy. The main problem I can see is that you have
to maintain (or be able to reconstruct) the absolute WAL offset of each
WAL record, because that number shows up in page LSNs in the data files.
There's also the question of keeping track of page boundaries in the WAL
files. And random access to a WAL segment would go by the wayside ---
I think you'd have to scan forward from the file start to locate the
checkpoint record you intend to replay from. The reader code would need
some nontrivial alterations to deal with all this, and you would
*definitely* need to know whether you were reading a compressed or
uncompressed WAL file.

I have zero interest in touching this problem for 8.0 ...

regards, tom lane

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-08-23 23:22:45 pgsql-server: Rearrange pg_subtrans handling as per recent discussion.
Previous Message Alvaro Herrera 2004-08-23 22:27:34 Re: PITR: XLog File compression on Archive