Re: Hot standby 9.2.6 -> 9.2.6 PANIC: WAL contains references to invalid pages

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: Sergey Konoplev <gray(dot)ru(at)gmail(dot)com>, matioli(dot)matheus(at)gmail(dot)com, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com>, Максим Панченко <Panchenko(at)gw(dot)tander(dot)ru>, Сизов Сергей Павлович <sizov_sp(at)gw(dot)tander(dot)ru>
Subject: Re: Hot standby 9.2.6 -> 9.2.6 PANIC: WAL contains references to invalid pages
Date: 2014-01-06 14:45:32
Message-ID: 20140106144532.GH28320@alap2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On 2014-01-06 16:35:42 +0200, Heikki Linnakangas wrote:
> >In btree_xlog_vacuum() we scan all the pages between lastBlockVacuumed
> >and the page vacuumed and acquire a cleanup lock on it. But there isn't
> >any guarantee that the intermediate pages are valid, filled pages,
> >afaics.
>
> Hmm. So the problem arises if there's an uninitialized page in the middle of
> the b-tree relation for some reason. It's unusual for an uninitialized page
> to be left in the middle of the relation, but it's certainly possible, if
> e.g you crash just after extending the relation. In a heap, vacuum will
> initialize such pages and emit a WARNING like "page %u is uninitialized ---
> fixing", but we don't do that for b-tree.

Yes. There's probably some resource exhaustion scenarios that can cause
this as well. Triggering *_timeout or out-of-memory errors at least...

> >ISTM we can just use RBM_ZERO_ON_ERROR instead of RBM_NORMAL.
>
> That'd be horrendously dangerous. It would silently zap any page with any
> error on it.

Well, the number of scenarios in which you can hit that is somewhat
limited - it's not going to be ENOSPC since the file is guaranteed to be
longer, and we don't create holes - so the scenario pretty much is disk
reads not returning (pretty rare) and checksums failing.

> But we could add a new ReadBufferMode that returns
> InvalidBuffer on error, without zeroing the page.

But yes, that's much better.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message m.sakrejda 2014-01-06 23:16:22 BUG #8728: Toast table much larger on replica
Previous Message Heikki Linnakangas 2014-01-06 14:38:16 Re: BUG #8686: Standby could not restart.

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-01-06 14:47:04 Re: ERROR: missing chunk number 0 for toast value
Previous Message Robert Haas 2014-01-06 14:43:45 Re: ERROR: missing chunk number 0 for toast value