Re: page corruption on 8.3+ that makes it to standby - Mailing list pgsql-hackers

From Tom Lane
Subject Re: page corruption on 8.3+ that makes it to standby
Date
Msg-id 16081.1280334996@sss.pgh.pa.us
Whole thread Raw
In response to Re: page corruption on 8.3+ that makes it to standby  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: page corruption on 8.3+ that makes it to standby
Re: page corruption on 8.3+ that makes it to standby
List 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 by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Toward a column reorder solution
Next
From: Kris Jurka
Date:
Subject: Re: [JDBC] Trouble with COPY IN