Hi John,

Since postgres uses presistent connection, it becomes the responsibilty of the client software to handle the disconnect, thus freeing connections. If connections are left dangling, over time postgres would run out of connection and users trying to access it would receive error message about no more connections. At that point, postgres would need to be restarted to free up connections.

In certain situation you would not want to use a persistent connection scheme, like a web app. In a web app I would advise that the connection be created when the user hit the submit button of a form, and closed immediately after postgres executes the insert, update, or delete command. All of this would take place in a faction of a second, so 32 connections could easily handle 300 or 400 concurrent users, because they would not all be sending SQL command at the same time.

Persistent connections are faster, but the trade-off is they use more resources like memory, cpu cycles, buffers, etc. Of course you can always increase the number of default connections postgres allow in postgresql.conf, like upto 1024. Anything about 1024 limit requires a rebuild of postgres from source with new configuation parameters. Also tuning is required regarding shared memory and buffer allowcations as connection limits are increased.

Although postgres will never timeout and disconnect a user, this could still happen at many other points, like the client or server OS, Software app like FoxPro can have timers that would disconnect an idle connection, or computer hardware like hub, router, etc can be programmed to timeout.