From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
---|---|
To: | "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | B-tree "finish incomplete split" bug |
Date: | 2008-06-11 08:25:37 |
Message-ID: | 484F8C01.1080201@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
While testing my xlogutils.c refactoring patch, I bumped into an
existing bug in the B-tree code that finishes an incomplete split:
btree_xlog_cleanup() calls _bt_insert_parent() to insert the parent
pointer. If the split page was the root page, _bt_insert_parent()
creates a new root page by calling _bt_newroot(). _bt_newroot() calls
CacheInvalidateRelcache() to notify other backends, but
CacheInvalidateRelcache causes a segfault when called during WAL replay,
because the invalidation infrastructure hasn't been initialized yet.
This bug was introduced in 8.2, when we started to cache metapage
information in relcache. It's no wonder that no-one has bumped into this
in the field, as the window for that to happen is extremely small; I had
to inject an "XLogFlush(); elog(PANIC)" into _bt_split to trigger it. I
wish we had regression tests for WAL recovery :-(.
The trivial fix is to not call CacheInvalidateRelcache() in recovery
(patch attached). Another option is to put the check into
CacheInvalidateRelcache() itself, but in the name of consistency we
should then put the same check into the other CacheInvalidate* variants
as well. As nbtinsert.c is the only place that calls
CacheInvalidateRelcache during WAL replay, I'm going to do the trivial fix.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
fix-finish-split-1.patch | text/x-diff | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2008-06-11 08:40:12 | Re: Proposal - improve eqsel estimates by including histogram bucket numdistinct statistics |
Previous Message | Csaba Nagy | 2008-06-11 07:02:41 | Re: Runtime checking of MCV (Was: ... histogram bucket numdistinct statistics) |