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
>
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 |