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

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, 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-14 13:54:32
Message-ID: 52D54198.7090802@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On 01/14/2014 03:59 AM, Tom Lane wrote:
> BTW, while I'm looking at this ... the writing side of the code seems a
> few bricks shy of a load too:
>
> /*
> * InHotStandby we need to scan right up to the end of the index for
> * correct locking, so we may need to write a WAL record for the final
> * block in the index if it was not vacuumed. It's possible that VACUUMing
> * has actually removed zeroed pages at the end of the index so we need to
> * take care to issue the record for last actual block and not for the
> * last block that was scanned. Ignore empty indexes.
> */
> if (XLogStandbyInfoActive() &&
> num_pages > 1 && vstate.lastBlockVacuumed < (num_pages - 1))
> {
> Buffer buf;
>
> /*
> * We can't use _bt_getbuf() here because it always applies
> * _bt_checkpage(), which will barf on an all-zero page. We want to
> * recycle all-zero pages, not fail. Also, we want to use a
> * nondefault buffer access strategy.
> */
> buf = ReadBufferExtended(rel, MAIN_FORKNUM, num_pages - 1, RBM_NORMAL,
> info->strategy);
> LockBufferForCleanup(buf);
> _bt_delitems_vacuum(rel, buf, NULL, 0, vstate.lastBlockVacuumed);
> _bt_relbuf(rel, buf);
> }
>
> If the last physical page of the index is all-zero, the preceding loop
> won't have any problem with that (nor should it); but this code sure will
> have a problem, because _bt_delitems_vacuum isn't prepared to cope with an
> all-zero page AFAICS.

Yep, that's broken.

> Nor am I following the logic of the initial comment. If we know that
> pages above N are all-zero, why are we worried about taking locks on them?
> There shouldn't be any scans reaching such pages, and any that did would
> error out anyhow in _bt_getbuf().

Also, btree relations are never truncated, so the comment is wrong when
it claims that VACUUM might've removed zero pages at the end of the index.

> ISTM the right thing here is for the btvacuumpage loop to remember the
> last ordinary, valid index page it saw, and point to that one in this
> added WAL entry.

Agreed.

- Heikki

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Ufuk Kayserilioglu 2014-01-14 13:59:29 Re: BUG #8821: pg_trgm segfault with Turkish locale database
Previous Message Дмитрий Сарафанников 2014-01-14 13:27:20 Re[2]: [BUGS] BUG #8757: Dublicate rows, broken primary key.

Browse pgsql-hackers by date

  From Date Subject
Next Message Oskari Saarenmaa 2014-01-14 13:55:30 Re: [PATCH] Filter error log statements by sqlstate
Previous Message Andres Freund 2014-01-14 13:44:48 Re: Extending BASE_BACKUP in replication protocol: incremental backup and backup format