Re: page corruption on 8.3+ that makes it to standby
От | Jeff Davis |
---|---|
Тема | Re: page corruption on 8.3+ that makes it to standby |
Дата | |
Msg-id | 1280264927.8505.57.camel@jdavis-ux.asterdata.local обсуждение исходный текст |
Ответ на | Re: page corruption on 8.3+ that makes it to standby (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: page corruption on 8.3+ that makes it to standby
|
Список | pgsql-hackers |
On Tue, 2010-07-27 at 15:50 -0400, Robert Haas wrote: > > 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. > > It appears to me that all of the callers of log_newpage() other than > copy_relation_data() do so with pages that they've just constructed, > and which therefore can't be new. So maybe we could just modify > copy_relation_data to check PageIsNew(buf), or something like that, > and only call log_newpage() if that returns true. My first concern with that idea was that it may create an inconsistency between the primary and the standby. The primary could have a bunch of zero pages that never make it to the standby. However, it looks like all WAL recovery stuff passes true for "init" when calling XLogReadBuffer(), so I think it's safe. I'll test it and submit a patch. Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: