From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: page corruption on 8.3+ that makes it to standby |
Date: | 2010-07-28 16:36:36 |
Message-ID: | 16081.1280334996@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2010-07-28 16:53:49 | Re: [HACKERS] Trouble with COPY IN |
Previous Message | Joshua D. Drake | 2010-07-28 16:33:42 | Re: Toward a column reorder solution |