On Wed, Jul 28, 2010 at 3:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> (1) You're assuming that the page will be zeroes on the slave without
> having forced it to be so. A really obvious case where this fails
> is where we're doing crash-and-restart on the master: a later action
> could have modified the page away from the all-zero state. (In
> principle that's OK but I think this might break torn-page protection.)
Hmm, yeah, that does seem like it has the potential to be bad. I
think this is sufficient reason to go with fix #1.
> (2) On filesystems that support holes, the page will not have storage,
> whereas it (probably) does on the master. This could lead to a
> divergence in behavior later, ie slave runs out of disk space at a
> different point than the master.
I can't get excited about this one.
> (3) The position of the nominal EOF can drive choices about which page
> to put new tuples in, specifically thats where RelationGetBufferForTuple
> will go if FSM has no information. This could result in unexpected
> divergence in behavior after the slave goes live compared to what the
> master would have done. Maybe that's OK but it seems better to avoid
> it if we can, especially when you think about crash-and-restart on the
> master as opposed to a separate slave.
You're still going to have that in the "normal" (not altering the
tablespace) extension case, which is presumably far more common.
The Enterprise Postgres Company
In response to
pgsql-hackers by date
|Next:||From: James William Pye||Date: 2010-07-28 20:19:26|
|Subject: Re: [HACKERS] Trouble with COPY IN |
|Previous:||From: Tom Lane||Date: 2010-07-28 19:37:49|
|Subject: Re: page corruption on 8.3+ that makes it to standby |