Pessoal, primeiramente parece-me que as conexões ficam pendentes ou até mesmo presas, porque se fossem perdidas o problema não estaria ocorrendo.

Bem, o keepalive se for possível pode ser um paliativo, mas não me parece uma solução definitiva.

Não vejo problema em ter 70 estações que se conectam ao servidor pela manhã e desconectam a noite e que me fazem ter um max_connection=100, por exemplo. O que me incomoda é ter um no-break de 12 KWA que não segura a rede durante um pico de entrada e que deixa 70 conexões ativas no servidor. Então basta a energia voltar que apenas as 30 primeiras máquinas conseguem conexão.

Pior ainda é que para resolver definitivamente (ou até o próximo pico de energia) é necessário fazer um stop seguido de start no banco.

Eu sinceramente não consigo conceber o PostgreSQL recusando conexões alegando que o número máximo de conexões foi atingido sem se dar conta de que os clientes abortaram as conexões.

Ninguém nunca viu isso antes, na hackers ou outra do gênero?

Abraços,

Em 05/01/2010 15:05, Fabrízio de Royes Mello escreveu:

2010/1/4 Tarcísio Sassara <[email protected]>

<corte>

Se o aplicativo que faz uso do postgres abre uma conexão e mantem está
até o fechamento, provavelmente a sessão passa uma boa parte do tempo
idle e pode ser uma boa configurar o keepalive.

Se for útil o keepalive, podemos discutir aqui uma boa configuração.


Vejamos se compreendi bem... dessa forma então eu precisaria modificar também a minha aplicação, para verificar se a conexão está ativa no momento de alguma transação com o banco de dados???? Pq se a conexao ficar idle por algum tempo (o usuário entra numa tela e sai pra tomar um café), com uma configuração diferenciada do keepalive a conexão será desfeita então terei de tratar isso na aplicação... certo???


--
Fabrízio de Royes Mello
>> Blog sobre TI: http://fabriziomello.blogspot.com
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

-- 
Sergio Medeiros Santi


_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a