Re: Problems with max_connections parameter

From: Jorge Augusto Meira <jmeira(at)c3sl(dot)ufpr(dot)br>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Problems with max_connections parameter
Date: 2010-12-14 01:46:37
Message-ID: AANLkTinX0vdLmApLc-GZ42FXesSoCRvUcuZGE3yyutho@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi again

Have something else I can do to reach the limit of the parameter
max_connections?

This may be a bug?

Thanks
Jorge

On Mon, Dec 6, 2010 at 1:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jorge Augusto Meira <jmeira(at)c3sl(dot)ufpr(dot)br> writes:
>> The error message was:
>> "Erro Conexão: A tentativa de conexão falhou."
>> or
>> "Erro Conexão: FATAL: connection limit exceeded for non-superusers"
>
> Hmm ... I can't find the first of those anywhere in the 8.4 message
> lists; but the second one definitely says that you *are* hitting the
> max_connections limit, whether you think you should be or not.
>
> I wonder whether you are neglecting to allow for the fact that backends
> have a nonzero shutdown time?  If you disconnect and immediately
> reconnect, it's possible that your old backend is still around, so that
> the new connection attempt causes max_connections to be exceeded.  This
> is particularly likely if the test program is on the same machine as the
> database server, because the test program itself is likely to have a
> higher scheduling priority than the old backend.
>
>                        regards, tom lane
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Ng, Stan 2010-12-14 02:18:33 index corruption on composite primary key indexes
Previous Message Andrey G. 2010-12-13 21:28:55 Re: BUG #5776: Unable to create view with parameter in PL/pgsql