In that case for the *slower* system I will recommend having a look at your database server logs and syslogs to see if it was a memory overcomitt that caused the disconnection. It might be an OOM killer here...
To my knowledge the multi-processing with PostgreSQL is dependent on how your OS schedules the processes across the multi-processer box. Which OS are you using? I guess 2.6 + Kernel can be a good option as I have seen it to perform good processes scheduling.
--
Shoaib Mir
EnterpriseDB (
www.enterprisedb.com)
On 2/4/07, Frank Bax <fbax@sympatico.ca> wrote: Script and database are both on same system. Faster system was able to get past next database access. So far so good, script continues to run. Still curious why it failed on slower system, though. Was this just a one-time "glitch"?
Background info: This is a *very* long running script (could be days) that initially loads data from database, then periodically updates database to let know current status of otherwise cpu-intensive process. Running on a P4 1.80Ghz processor, script got to one of the "status update" points in the process in 11:14 (hrs:min); a Core2Duo 1.86Ghz system took 4:06 (quite close to prediction) to reach same point in process. Script does not exploit multi-processors.
At 01:35 PM 2/3/07, Shoaib Mir wrote:
Make sure there is no firewall setting in between the database server and application that might be closing the connections...
--
Shoaib Mir
EnterpriseDB (www.enterprisedb.com )
On 2/3/07, Frank Bax <fbax@sympatico.ca> wrote:
Is there a connection timeout? I'm using DBD::Pg (1.47) in perl to access
8.2.1 database.
I've got a rather long running script; it does a bit of database access,
then did some other crunching for about 11-12 hours before making another
pgsql call; at which point, I get this error:
FATAL: This connection has been terminated by the administrator.
I've restarted my script on a faster system and expect to get to the same
point in about 4 hours this time. Hopefully timeout values won't get in
the way this time?
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
