Skip site navigation (1) Skip section navigation (2)

Re: page corruption on 8.3+ that makes it to standby

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: Kris JurkaDate: 2010-07-28 16:53:49
Subject: Re: [HACKERS] Trouble with COPY IN
Previous:From: Joshua D. DrakeDate: 2010-07-28 16:33:42
Subject: Re: Toward a column reorder solution

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group