The world rejoiced as augustz@augustz.com (August Zajonc) wrote:
> Ted Byers wrote:
>
> [snip]
>> It is outrageously unethical, IMHO, for a programmer, or group thereof,
>> to refuse to fix a problem that has arisen from how their targetted
>> users use their application.
>
> Let's save the determination of outrageous behavior for others and see
> if we can help the user fix their problem.
>
> Two suggestions:
> Pgpool
>
> Change keepalive settings in kernel if the machine is only used for
> postgresql. If you disable keepalives, at some point the kernel will
> likely drop the connection. Postgresql turns keepalives on by default
> (which is usually a good thing).
>
> Your apps should login transparently though and know how to handle this
> issue. Prompting users repeatedly to login can be frustrating, the usual
> question is how to keep a connection open longer :)
>
> I'm not sure that postgresql would itself implement a timeout feature...
This fits very nicely into the category of things that can reasonably
vary quite a lot based on local policy.
I'd quite like to be able to say:
"We can let some users in, with read-only access. And we can have
PostgreSQL enforce policies as to maximum connection times so that
we can ensure they do not hold open <IDLE> in transaction
connections that will destroy performance."
At present, I can only handle this via creating external utilities to
try to analyze things and look for connections that are breaking
connectivity policies. It would be rather nice to have something to
support this in the DB engine.
That may not fit your needs: your users may be in a position to tell
you "we don't care if performance suffers - we want our connections."
--
output = reverse("moc.liamg" "@" "enworbbc")
http://linuxdatabases.info/info/lsf.html
"Let me blow that up a bit more for you."
-- Colin Powell, Discussing a picture of the intelligence compound in
Iraq
