On Thu, Jan 24, 2013 at 7:42 AM, MauMau <maumau307@gmail.com> wrote:
> From: "Tom Lane" <tgl@sss.pgh.pa.us>
>
>> Since we've fixed a couple of relatively nasty bugs recently, the core
>> committee has determined that it'd be a good idea to push out PG update
>> releases soon. The current plan is to wrap on Monday Feb 4 for public
>> announcement Thursday Feb 7. If you're aware of any bug fixes you think
>> ought to get included, now's the time to get them done ...
>
>
> I've just encountered a serious problem, and I really wish it would be fixed
> in the upcoming minor release. Could you tell me whether this is already
> fixed and will be included?
>
> I'm using synchronous streaming replication with PostgreSQL 9.1.6 on Linux.
> There are two nodes: one is primary and the other is a standby. When I
> performed failover tests by doing "pg_ctl stop -mi" against the primary
> while some applications are reading/writing the database, the standby
> crashed while it was performing recovery after receiving promote request:
>
> ...
> LOG: archive recovery complete
> WARNING: page 506747 of relation base/482272/482304 was uninitialized
> PANIC: WAL contains references to invalid pages
> LOG: startup process (PID 8938) was terminated by signal 6: Aborted
> LOG: terminating any other active server processes
> (the log ends here)
>
> The mentioned relation is an index. The contents of the referred page was
> all zeros when I looked at it with "od -t x $PGDATA/base/482272/482304.3"
> after the crash. The subsequent pages of the same file had valid-seeming
> contents.
>
> I searched through PostgreSQL mailing lists with "WAL contains references to
> invalid pages", and i found 19 messages. Some people encountered similar
> problem. There were some discussions regarding those problems (Tom and
> Simon Riggs commented), but those discussions did not reach a solution.
>
> I also found a discussion which might relate to this problem. Does this fix
> the problem?
>
> [BUG] lag of minRecoveryPont in archive recovery
> http://www.postgresql.org/message-id/20121206.130458.170549097.horiguchi.kyotaro@lab.ntt.co.jp
Yes. Could you check whether you can reproduce the problem on the
latest REL9_2_STABLE?
Regards,
--
Fujii Masao