Обсуждение: Bug #436: backend closed the channel unexpectedly

Michael Ablass (ma@netresearch.de) reports a bug with a severity of 1
The lower the number the more severe it is.

Short Description
backend closed the channel unexpectedly

Long Description
Using Postgresql 7.1.3 on Redhat 7.1 and 6.2, currently we have 2 projects running. a few days the databases do work
perfectly- then we get error message following. it seems not to be the problem of certain sql queries as sometimes
everythingworks and sometimes it does. we increased the amount of connections but it did not help. next thing: on
redhat6.2 the database seems to work more unstable than on the redhat 7.1 server. 

Warning: PostgreSQL query failed: FATAL 1: This connection has been terminated by the administrator. pqReadData() --
backendclosed the channel unexpectedly. This probably means the backend terminated abnormally before or while
processingthe request. in /shares/maxtor1/home/httpd/server/global_classes/db_pgsql.inc on line 69 
Database error: Invalid SQL: SELECT * from offen where o_id='1' AND o_offen='J'
PostgreSQL Error: 1 (FATAL 1: This connection has been terminated by the administrator. pqReadData() -- backend closed
thechannel unexpectedly. This probably means the backend terminated abnormally before or while processing the request.
)
Session halted.

Sample Code


No file was uploaded with this report

pgsql-bugs@postgresql.org writes:
> Using Postgresql 7.1.3 on Redhat 7.1 and 6.2, currently we have 2
> projects running. a few days the databases do work perfectly - then we
> get error message following.

> Warning: PostgreSQL query failed: FATAL 1: This connection has been
> terminated by the administrator.

This message indicates that the backend got a SIGTERM signal from
someplace.  If the postmaster got a SIGINT signal it would turn around
and SIGTERM all the backends, but there's no other mechanism in Postgres
that would cause this to happen.

Is the postmaster still alive after the backends shut down, or does it
quit too?  What shows up in the postmaster's stderr log?  (If you're
sending stderr to /dev/null, now is a good time to stop doing so.)

            regards, tom lane