Sorry for that. The bug was incorrect calculation of XNOOP record
size in GiST WAL when incremental log is created from the full backup.
Because the bug impact is so serious, I'm rebuilding the test
environment which is taking long. I'll report the cause of the bug
to hackers and bugs.
If GiST is not used, WAL compression works correctly but I'm not
comfortable to use lesslog with known bug.
----------
Koichi Suzuki
2010/3/13 Bruce Momjian <bruce@momjian.us>:
> Nicos Panayides wrote:
>> Hi,
>> I am planning an off-site backup solution for a fairly busy
>> (mostly-write) 8.3 database. The database is currently about 200GB in
>> size. I though about using log shipping and cold standby since it's easy
>> in terms of administration and also offers point in time recovery.
>>
>> The database generates about 3 PITR log files per minute. If my
>> calculations are correct the sites need to be connected with a 7MBit
>> connection and the logs will need about 68GB of storage per day!
>>
>> Does anyone have any suggestions on how to significantly reduce the
>> volume of log files or recommend another off-site backup solution that
>> would require less bandwidth and storage?
>
> I would use pg_lesslog to reduce the size of the WAL files:
>
> http://pgfoundry.org/projects/pglesslog/
>
> However, there is a bug in pg_lesslog so I wouldn't use it until that is
> fixed:
>
> http://archives.postgresql.org/pgsql-announce/2010-02/msg00005.php
>
> Koichi, do you have any update on this? I don't see that a new version
> has been uploaded, and I also see no mention on the pgfoundry site about
> the bug.
>
> --
> Bruce Momjian <bruce@momjian.us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
>
