Re: connection timeout?

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(at)sympatico(dot)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(at)sympatico(dot)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
>
>