From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: GIN needs tonic |
Date: | 2009-09-15 06:41:56 |
Message-ID: | 4AAF3734.5030406@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Simon Riggs wrote:
> In recovery of GIN operations using CVS HEAD I see consistently
>
> TRAP: FailedAssertion("!(((bool) ((spcNode) != ((Oid) 0))))", File:
> "tablespace.c", Line: 116)
>
> Looking at code, "new list page" WAL record is a GIN record type and at
> line 115 in gin/ginfast.c I see that the value of the node is unset.
> That means XLOG_GIN_INSERT_LISTPAGE always has specNode == 0 and so
> triggers the assertion failure.
Yeah, so it seems. The fix should be as simple as:
--- a/src/backend/access/gin/ginfast.c
+++ b/src/backend/access/gin/ginfast.c
@@ -121,6 +121,7 @@ writeListPage(Relation index, Buffer buffer,
rdata[1].len = size;
rdata[1].next = NULL;
+ data.node = index->rd_node;
data.blkno = BufferGetBlockNumber(buffer);
data.rightlink = rightlink;
data.ntuples = ntuples;
This means that the WAL replay of that record type has never been tested
correctly :-(. Looking closer at writeListPage(), why does it always
include 'workspace' in the WAL record, even if a full-page-image is
taken? It's not used for anything the the redo function. That's
harmless, but bloats the WAL record unnecessary. In fact it might be
better to never do full-page writes for that record type, since it
completely overwrites the page anyway.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2009-09-15 08:08:41 | Re: GIN needs tonic |
Previous Message | Craig Ringer | 2009-09-15 06:32:06 | Re: BUG #5055: Invalid page header error |