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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
