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....@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 <k...@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 >> >> > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
