[HACKERS] page corruption on 8.3+ that makes it to standby
in [PgSql]
|
Prev: do we need to postpone beta4?
Next: [HACKERS] ALTER TABLE ... DISABLE TRIGGER vs. AccessExclusiveLock
From: Jeff Davis on 27 Jul 2010 14:06 I reported a problem here: http://archives.postgresql.org/pgsql-bugs/2010-07/msg00173.php Perhaps I used a poor subject line, but I believe it's a serious issue. That reproducible sequence seems like an obvious bug to me on 8.3+, and what's worse, the corruption propagates to the standby as I found out today (through a test, fortunately). The only mitigating factor is that it doesn't actually lose data, and you can fix it (I believe) with zero_damaged_pages (or careful use of dd). There are two fixes that I can see: 1. Have log_newpage() and heap_xlog_newpage() only call PageSetLSN() and PageSetTLI() if the page is not new. This seems slightly awkward because most WAL replay stuff doesn't have to worry about zero pages, but in this case I think it does. 2. Have copy_relation_data() initialize new pages. I don't like this because (a) it's not really the job of SET TABLESPACE to clean up zero pages; and (b) it could be an index with different special size, etc., and it doesn't seem like a good place to figure that out. Comments? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |