Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id B020E1B5234D for ; Wed, 23 May 2012 18:33:43 -0300 (ADT) Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SXJBe-0004MO-LH for pgsql-admin@postgresql.org; Wed, 23 May 2012 21:33:43 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id q4NLXTR1012775; Wed, 23 May 2012 17:33:29 -0400 (EDT) To: Vincent Dautremont cc: pgsql-admin@postgresql.org Subject: Re: out of memory error In-reply-to: References: <3902.1337708023@sss.pgh.pa.us> <5105.1337711403@sss.pgh.pa.us> <7269.1337717095@sss.pgh.pa.us> <4392.1337786802@sss.pgh.pa.us> Comments: In-reply-to Vincent Dautremont message dated "Wed, 23 May 2012 17:22:07 -0400" Date: Wed, 23 May 2012 17:33:29 -0400 Message-ID: <12774.1337808809@sss.pgh.pa.us> From: Tom Lane X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201205/89 X-Sequence-Number: 39578 Vincent Dautremont writes: > you were right, > I do see those CREATE OR REPLACE FUNCTION a bit more than 1 per second > (approx. 12 times for 10 seconds) Hah. Complain to the rubyrep people. It's most likely just a thinko about where they should issue that command. If they actually are changing the function text from one issuance to the next, they would be well advised to think of a better way to deal with whatever they're doing that for; it's going to be quite inefficient even without considering the effects of this leak. > I don't know a lot about the internal of rubyrep, but do you think this is > not a normal behaviour from a postgresql server point of view ? It's not. We have plugged that leak, I think, as of 9.1; but the fact that it took us this long to notice the leak shows that constant replacement of a function is not a common usage. All the server's internal caching related to functions is designed around the assumption that functions aren't redefined too often. If you can't get the rubyrep people to fix their code, updating to PG 9.1 is a possible workaround. regards, tom lane