Excerpts from Alvaro Herrera's message of lun dic 12 17:20:39 -0300 2011:
> I found that this is caused by mxid_to_string being leaked all over the
> place :-( I "fixed" it by making the returned string be a static that's
> malloced and then freed on the next call. There's still virtsize growth
> (not sure it's a legitimate leak) with that, but it's much smaller.
this fixes the remaining leaks. AFAICS it now grows to a certain point
and it's fixed size after that. I was able to share-lock a 10M rows
table with a 30MB RSS process.
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index 49d3369..7069950 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -3936,6 +3936,8 @@ l3: keep_xmax = xwait; keep_xmax_multi = true;
}
+
+ pfree(members); } } else if (infomask &
HEAP_XMAX_KEYSHR_LOCK)
@@ -4693,6 +4695,9 @@ GetMultiXactIdHintBits(MultiXactId multi) if (!has_update) bits |=
HEAP_XMAX_IS_NOT_UPDATE;
+ if (nmembers > 0)
+ pfree(members);
+ return bits;}
@@ -4743,6 +4748,8 @@ HeapTupleGetUpdateXid(HeapTupleHeader tuple) break;#endif }
+
+ pfree(members); } return update_xact;
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
