Received: from mail.pacbell.net (adsl-63-204-248-30.dsl.lsan03.pacbell.net [63.204.248.30]) by mail.postgresql.org (8.11.1/8.11.1) with ESMTP id f281EFx89525 for ; Wed, 7 Mar 2001 20:14:15 -0500 (EST) (envelope-from bhso@pacbell.net) Received: (from bhso@localhost) by mail.pacbell.net (8.9.3/8.9.3) id RAA16147; Wed, 7 Mar 2001 17:14:05 -0800 X-Authentication-Warning: blanc.pacbell.net: bhso set sender to bhso@pacbell.net using -f To: Tom Lane Cc: pgsql-interfaces@postgresql.org Subject: Re: Backend dies for DBI References: <22575.984012545@sss.pgh.pa.us> From: Bjorn Halvor Solberg Date: 07 Mar 2001 17:14:05 -0800 In-Reply-To: Tom Lane's message of "Wed, 07 Mar 2001 19:49:05 -0500" Message-ID: Lines: 53 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Archive-Number: 200103/78 X-Sequence-Number: 1239 Tom Lane writes: > Bjorn Solberg writes: >> The log file from postmaster simply says: ---> >> StartTransactionCommand >> [...] >> ProcessQuery >> CommitTransactionCommand >> proc_exit(0) >> shmem_exit(0) >> exit(0) >> /usr/local/pgsql/bin/postmaster: reaping dead processes... >> /usr/local/pgsql/bin/postmaster: CleanupProc: pid 1297 exited with status 0 >> proc_exit(0) >> shmem_exit(0) >> exit(0) >> /usr/local/pgsql/bin/postmaster: reaping dead processes... >> /usr/local/pgsql/bin/postmaster: CleanupProc: pid 1298 exited with status 0 >> ---< > This looks absolutely normal --- there's no evidence here for anything > except normal backend exit. At least the backend thinks it's normal. > You should be looking for client or protocol-level problems. OK. I thought it was abnormal because it only happens when DBI loses connection. >> DBI (I think) sometimes output a message like "Backend message type 0x50 >> arrived while idle". This can happen several times, and the crash does >> not occur directly following any of the messages. > This may indicate running out of memory for a query result on the client > side; libpq is not very graceful about dealing with that :-(. You > should check on the sizes of query results you are fetching and the > amount of memory available to your DBI applications. Fetching a few > rows at a time via a CURSOR is a good workaround if that seems to be > the problem. Thank you for your help, I'll look into this. I do check the result of each query, this is a very small database so I can't quite see how that would affect the system like this. What confuses me is that it ran fine for a couple of months. Then, after the power outage, it crashes every few hours, resulting in having to restart the web server to regain the DB handle. Currently the DB handle is allocated once at (web-)server startup. Maybe I'll change it to do a connect and disconnect for each web page instead. I figured doing it only once and reusing the DB handle would save some time, but maybe it is an unsafe thing to do? Bjorn.