[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?
> http://archives.postgresql.org/pgsql-admin/2005-08/msg00239.php
> http://archives.postgresql.org/pgsql-jdbc/2003-10/msg00109.php
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?
> http://www2.units.it/~nircdc/doc/php/ref.pgsql.html
> http://www.sitepoint.com/article/accessing-postgresql-php/3
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.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
- Re: [Gnumed-devel] encounter edit before final save, (continued)
- Re: [Gnumed-devel] encounter edit before final save, Karsten Hilbert, 2008/08/11
- Re: [Gnumed-devel] encounter edit before final save, Rogerio Luz, 2008/08/11
- Re: [Gnumed-devel] encounter edit before final save, Karsten Hilbert, 2008/08/11
- Re: [Gnumed-devel] encounter edit before final save, James Busser, 2008/08/13
- Re: [Gnumed-devel] encounter edit before final save, Karsten Hilbert, 2008/08/13
- Re: [Gnumed-devel] encounter edit before final save, James Busser, 2008/08/13
- Re: [Gnumed-devel] encounter edit before final save, Karsten Hilbert, 2008/08/15
- [Gnumed-devel] client tcp/ip and Postgres timeouts (was encounter edit before final save), James Busser, 2008/08/16
- Re: [Gnumed-devel] client tcp/ip and Postgres timeouts (was encounter edit before final save),
Karsten Hilbert <=
- Re: [Gnumed-devel] client tcp/ip and Postgres timeouts, James Busser, 2008/08/16
- Re: [Gnumed-devel] client tcp/ip and Postgres timeouts, Karsten Hilbert, 2008/08/16
- Re: [Gnumed-devel] encounter edit before final save, Jerzy Luszawski, 2008/08/11
- Re: [Gnumed-devel] encounter edit before final save, Karsten Hilbert, 2008/08/11
- Re: [Gnumed-devel] encounter edit before final save, James Busser, 2008/08/12
- access to review audits (was Re: [Gnumed-devel] encounter edit before final save), James Busser, 2008/08/12
- Re: access to review audits (was Re: [Gnumed-devel] encounter edit before final save), Jerzy Luszawski, 2008/08/13
- Re: access to review audits (was Re: [Gnumed-devel] encounter edit before final save), Karsten Hilbert, 2008/08/13
- Re: access to review audits (was Re: [Gnumed-devel] encounter edit before final save), Karsten Hilbert, 2008/08/13
- Re: access to review audits (was Re: [Gnumed-devel] encounter edit before final save), James Busser, 2008/08/13