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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: page corruption on 8.3+ that makes it to standby
Date: 2010-07-28 11:29:43
Message-ID: AANLkTik_xhUdihR-107VtH6d+4SmZYEqObpDtpm3qjv2@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 28, 2010 at 7:02 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Tue, 2010-07-27 at 21:23 -0700, Jeff Davis wrote:
>
>> Both potential fixes attached and both appear to work.
>>
>> fix1 -- Only call PageSetLSN/TLI inside log_newpage() and
>> heap_xlog_newpage() if the page is not zeroed.
>>
>> fix2 -- Don't call log_newpage() at all if the page is not zeroed.
>>
>> Please review. I don't have a strong opinion about which one should be
>> applied.
>
> ISTM we should just fix an uninitialized page first, using code from
> VACUUM similar to
>
>  if (PageIsNew(page))
>  {
>    ereport(WARNING,
>        (errmsg("relation \"%s\" page %u is uninitialized --- fixing",
>                                                relname, blkno)));
>    PageInit(page, BufferGetPageSize(buf), 0);
>  }
>
> then continue as before.

As Jeff Davis pointed out upthread, you don't know that 0 is the
correct special size for the relation being copied. In the VACUUM
path, that code is only applied to heaps, but that's not necessarily
the case here.

> We definitely shouldn't do anything that leaves standby different to
> primary.

Obviously.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-07-28 11:30:48 Re: Query optimization problem
Previous Message Yeb Havinga 2010-07-28 11:24:56 Re: Query optimization problem