In addition, in the fix, I'm thinking I should add at least the
following check mechanism;
1. Check XNOOP record size to match the original WAL record.
2. Restore WAL segment at the time of pg_compress, compare restored
WAL with the original and check it is safe to use in the restoration,
both each WAL record and whole WAL segment.
----------
Koichi Suzuki
2010/2/12 Koichi Suzuki <koichi.szk@gmail.com>:
> Thank you very much for the advice. Yes I think it should go to
> announce. I will post a message.
> ----------
> Koichi Suzuki
>
>
>
> 2010/2/12 Karl Denninger <karl@denninger.net>:
>> Joshua D. Drake wrote:
>>
>> On Thu, 2010-02-11 at 23:39 +0900, Koichi Suzuki wrote:
>>
>>
>> Dear Folks;
>>
>> A very serious bug was reported on pg_lesslog. So far, I found it's
>> a bug in pg_compresslog. Please do not use pg_compresslog and
>> pg_decompresslog until improved version is uploaded.
>>
>> I strongly advise to take base backup of your database.
>>
>> I apologize for inconvenience. I'll upload the new version ASAP.
>>
>>
>> Should this go out on announce?
>>
>>
>> I certainly think so. Anyone who gets caught "by surprise" on this could
>> quite possibly lose all their data!
>>
>> I (fortunately) caught it during TESTING of my archives - before I needed
>> them.
>>
>> -- Karl Denninger
>>
>>
>