2010/1/5 Sergio Santi <[email protected]>: > 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.
Justamente, isso não é problema. O problema é quando as máquinas são desligadas abruptamente. > 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. É ai que entra o keepalive_idle. Não entendi direito, quando você disse a rede, quis dizer as estações (70 maquinas) certo? Quando estas maquinas caírem, as conexões serão perdidas. Para o postgres saber quando estas foram perdidas e que devem ser eliminadas você deve usar o keepalive. > 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? Sim, existe algumas discussões lá sobre este assunto mas que não existe uma solução melhor do que essa. Pelo que entendo, o problema é uma questão de rede e do protocolo TCP. Quando uma máquina é rancada da tomada, o servidor não é avisado. Só saberá quando terminar a transação e enviar para o cliente. Por isso fica a conexão rodando. -- Tarcisio F. Sassara _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
