Re: page corruption on 8.3+ that makes it to standby
От | Tom Lane |
---|---|
Тема | Re: page corruption on 8.3+ that makes it to standby |
Дата | |
Msg-id | 16081.1280334996@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: page corruption on 8.3+ that makes it to standby (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: page corruption on 8.3+ that makes it to standby
Re: page corruption on 8.3+ that makes it to standby |
Список | pgsql-hackers |
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.) regards, tom lane
В списке pgsql-hackers по дате отправления: