[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] client tcp/ip and Postgres timeouts (was encounter ed

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] client tcp/ip and Postgres timeouts (was encounter edit before final save)
Date: Sat, 16 Aug 2008 12:34:12 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Fri, Aug 15, 2008 at 09:02:12PM -0700, James Busser wrote:

>>> Is there however a
>>> caveat with respect to a "timeout" after which the database will not
>>> allow the paused instance to write into the backend?
>> There is, at the purely technical level.
>>> Where and how would this configuration be set?
>> The TCP/IP stack timeout is one place I can think of.
> Is the above (the TCP/IP stack timeout setting) managed at a system  
> level on both the client computer and on the server?
Yes, and also at possible machines inbetween, say a
firewall, router, or Network Address Translation gateway.
Not all of them are controllable by the local user.

> ... looks like a default may be 60 seconds but maybe something else  
> would keep the client connection alive?
> Are connection timeout limits further managed within PostgreSQL or only 
> if we configure them to be so?

Tom $God Lane attests to PostgreSQL not having let alone
applying a timeout to idle connections - which is well in
spirit with other PG behaviour. He suggests running an empty
query every so often.

If dropped connections appear to become a problem I'll add
that to GNUmed.

>       ... postgres evidently includes some "persistence" configurations
>       ... however are we decided to avoid or limit persistence?

No, that only applies to mechanisms available from within PHP.

> If the above is correct, then the timeout would in practice be  
> determined by whichever is the shortest of the above?

It is not, but the conclusion would be correct if it were.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]