Skip site navigation (1) Skip section navigation (2)

Re: out of memory error

From: Vincent Dautremont <vincent(at)searidgetech(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: out of memory error
Date: 2012-05-23 21:46:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
Thank you very much for your help, it's greatly appreciated.
At least I can now pinpoint the problem and search for a solution or
another reason to upgrade to 9.1 !


On Wed, May 23, 2012 at 5:33 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Vincent Dautremont <vincent(at)searidgetech(dot)com> 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

In response to

pgsql-admin by date

Next:From: Adam FuchsDate: 2012-05-24 21:31:57
Subject: PG_DUMP producing lots of WAL archive logs
Previous:From: Tom LaneDate: 2012-05-23 21:33:29
Subject: Re: out of memory error

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group