On Tue, Jul 27, 2010 at 5:08 PM, Jeff Davis <pg...@j-davis.com> wrote: > 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.
Maybe I'm slow on the uptake here, but don't the pages start out all-zeroes on the standby just as they do on the primary? The only way it seems like this would be a problem is if a page that previously contained data on the primary was subsequently zeroed without writing a WAL record - or am I confused? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
