Hi,

We've been hit by a pg_freespacemap contrib module crash (SIGSEGV), gdb showed 
it was in line 162 of it's pg_freespacemap.c file. 
        fctx->record[i].reltablespace = fsmrel->key.spcNode;

Thanks to Andrew Gierth (irc:RhodiumToad) and after some analysis and  we've 
been able to understand what happened: MaxFSMPages is not the maximum number 
of elements (tables and indexes) contained into the FSM memory, and the 
contrib believes it is.

In fact, AFAUI this number is computed from the max_fsm_pages setting applying 
to it the 6 bytes per table. When you put in there some index FSM information, 
you need 4 bytes. So you can store more items than max_fsm_pages * 6 bytes.

Please find attached a "stupid" patch for the case not to happen again here, I 
suppose you'll want some more refined solution to get into -core.

Regards,
-- 
dim

PS: of course any faulty reasoning here would be mine, and we still have the 
evidences around (core).
diff -Nur -x '*.orig' -x '*~' postgresql-8.2-8.2.11/build-tree/postgresql-8.2.11/contrib/pg_freespacemap/pg_freespacemap.c postgresql-8.2-8.2.11.new/build-tree/postgresql-8.2.11/contrib/pg_freespacemap/pg_freespacemap.c
--- postgresql-8.2.11/contrib/pg_freespacemap/pg_freespacemap.c	2006-10-19 20:32:46.000000000 +0200
+++ postgresql-8.2.11/contrib/pg_freespacemap/pg_freespacemap.c	2009-04-07 12:15:13.000000000 +0200
@@ -102,7 +102,7 @@
 		 */
 		FreeSpaceMap = GetFreeSpaceMap();
 
-		numPages = MaxFSMPages;
+		numPages = MaxFSMPages * 2;
 
 		funcctx = SRF_FIRSTCALL_INIT();
 

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to