From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bjorn Solberg <bjorn(at)geocities(dot)com> |
Cc: | pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: Backend dies for DBI |
Date: | 2001-03-08 00:49:05 |
Message-ID: | 22575.984012545@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
Bjorn Solberg <bjorn(at)geocities(dot)com> 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.
> 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bjorn Halvor Solberg | 2001-03-08 01:14:05 | Re: Backend dies for DBI |
Previous Message | Timothy H. Keitt | 2001-03-08 00:03:26 | unbuffered results from libpq? |