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 по дате отправления: