Noah, Many thanks for this review. I'm going through items on it; definitely there are serious issues here, as well as minor things that also need fixing. Thanks for all the detail.
I'll post an updated patch shortly (probably not today though); in the meantime, this bit: Excerpts from Noah Misch's message of dom dic 04 09:20:27 -0300 2011: > Second, I tried a SELECT FOR SHARE on a table of 1M tuples; this might incur > some cost due to the now-guaranteed use of pg_multixact for FOR SHARE. See > attached fklock-test-forshare.sql. The median run slowed by 7% under the > patch, albeit with a rather brief benchmark run. Both master and patched > PostgreSQL seemed to exhibit a statement-scope memory leak in this test case: > to lock 1M rows, backend-private memory grew by about 500M. When trying 10M > rows, I cancelled the query after 1.2 GiB of consumption. This limited the > duration of a convenient test run. 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 being a debugging aid, I don't think there's any need to backpatch this. diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c index ddf76b3..c45bd36 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -1305,9 +1305,14 @@ mxstatus_to_string(MultiXactStatus status) static char * mxid_to_string(MultiXactId multi, int nmembers, MultiXactMember *members) { - char *str = palloc(15 * (nmembers + 1) + 4); + static char *str = NULL; int i; + if (str != NULL) + free(str); + + str = malloc(15 * (nmembers + 1) + 4); + snprintf(str, 47, "%u %d[%u (%s)", multi, nmembers, members[0].xid, mxstatus_to_string(members[0].status)); -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers