Re: page corruption on 8.3+ that makes it to standby
От | Robert Haas |
---|---|
Тема | Re: page corruption on 8.3+ that makes it to standby |
Дата | |
Msg-id | AANLkTik_xhUdihR-107VtH6d+4SmZYEqObpDtpm3qjv2@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: page corruption on 8.3+ that makes it to standby (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-hackers |
On Wed, Jul 28, 2010 at 7:02 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Tue, 2010-07-27 at 21:23 -0700, Jeff Davis wrote: > >> Both potential fixes attached and both appear to work. >> >> fix1 -- Only call PageSetLSN/TLI inside log_newpage() and >> heap_xlog_newpage() if the page is not zeroed. >> >> fix2 -- Don't call log_newpage() at all if the page is not zeroed. >> >> Please review. I don't have a strong opinion about which one should be >> applied. > > ISTM we should just fix an uninitialized page first, using code from > VACUUM similar to > > if (PageIsNew(page)) > { > ereport(WARNING, > (errmsg("relation \"%s\" page %u is uninitialized --- fixing", > relname, blkno))); > PageInit(page, BufferGetPageSize(buf), 0); > } > > then continue as before. As Jeff Davis pointed out upthread, you don't know that 0 is the correct special size for the relation being copied. In the VACUUM path, that code is only applied to heaps, but that's not necessarily the case here. > We definitely shouldn't do anything that leaves standby different to > primary. Obviously. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
В списке pgsql-hackers по дате отправления: