Re: foreign key locks, 2nd attempt

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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support