Re: foreign key locks, 2nd attempt - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: foreign key locks, 2nd attempt
Date
Msg-id 1323720855-sup-3526@alvh.no-ip.org
Whole thread Raw
In response to Re: foreign key locks, 2nd attempt  (Noah Misch <noah@leadboat.com>)
Responses Re: foreign key locks, 2nd attempt  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: foreign key locks, 2nd attempt  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
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 <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: static or dynamic libpgport
Next
From: Dimitri Fontaine
Date:
Subject: Re: Command Triggers