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 1280337508.9421.28.camel@jdavis
обсуждение исходный текст
Ответ на Re: page corruption on 8.3+ that makes it to standby  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, 2010-07-28 at 12:36 -0400, Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
> > However, when Simon said "We definitely shouldn't do anything that
> > leaves standby different to primary." you said "obviously". Fix2 can
> > leave a difference between the two, because zeroed pages at the end of
> > the heap file on the primary will not be sent to the standby (the
> > standby will only create the zeroed pages if a higher block number is
> > sent; which won't be the case if the zeroed pages are at the end).
> 
> > As we discussed before, that looks inconsequential, but I just want to
> > make sure that it's understood.
> 
> I understand it, and I don't like it one bit.  I haven't caught up on
> this thread yet, but I think the only acceptable solution is one that
> leaves the slave in the *same* state as the master.  Not a state that
> we hope will behave equivalently.  I can think of too many corner cases
> where it might not.  (In fact, having a zeroed page in a relation is
> already a corner case in itself, so the amount of testing you'd get for
> such behaviors is epsilon squared.  You don't want to take that bet.)
> 

Ok, sounds like my original fix (fix1) is the way to go then. Log zero
pages, but don't set LSN/TLI if it's a zero page (in log_newpage or
heap_xlog_newpage).

Regards,Jeff Davis



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kris Jurka
Дата:
Сообщение: Re: [JDBC] Trouble with COPY IN
Следующее
От: Robert Haas
Дата:
Сообщение: Re: page corruption on 8.3+ that makes it to standby