Thread

1. backend closed the channel unexpectedly?!?

   Martti Hertzen <hertzma@sqc.fi> — 2000-11-08T14:54:40Z

   Hi,
   
   I don't know if this is the right place to ask this (and I'm sorry if
   this isn't) but here is a little problem I encountered. I have been
   using postgres in a redhat linux 6.1 for nearly 6 month and it has been
   working fine until today. I have a table with a field called 'id'
   (primary key) that is referenced from other tables. Today I tried to
   delete one of the rows in this table with the following command (worked
   fine a few weeks ago) and there's the output. It does that each and
   every time I try to update the primary key or delete a row. I've stoped
   and started the postmaster several times of course.
   
   testsqc=> DELETE FROM henkilo WHERE id = 12;
   pqReadData() -- backend closed the channel unexpectedly.
           This probably means the backend terminated abnormally
           before or while processing the request.
   The connection to the server was lost. Attempting reset: Failed.
   !>
   
   Here's the output of the debug channel:
   
   001108.16:31:16.753 [31195] StartTransactionCommand
   001108.16:31:16.753 [31195] query: DELETE FROM henkilo WHERE id = 12;
   001108.16:31:16.840 [31195] ProcessQuery
   postmaster: reaping dead processes...
   postmaster: CleanupProc: pid 31195 exited with status 139
   Server process (pid 31195) exited with status 139 at Wed Nov  8 16:31:17
   2000
   Terminating any active server processes...
   Server processes were terminated at Wed Nov  8 16:31:17 2000
   Reinitializing shared memory and semaphores
   001108.16:31:17.822 [30871] shmem_exit(0)
   binding ShmemCreate(key=52e4b5, size=1104896)
   
   etc...
   
   Is this a known problem with a solution to it?
   
   Thanks,
   --
   Martti Hertzen
   
   PS:
   testsqc=> select version();
                                  version
   ---------------------------------------------------------------------
    PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66
   (1 row)
   
   

2. Re: backend closed the channel unexpectedly?!?

   Tom Lane <tgl@sss.pgh.pa.us> — 2000-11-08T15:03:07Z

   Martti Hertzen <hertzma@sqc.fi> writes:
   > I have a table with a field called 'id'
   > (primary key) that is referenced from other tables. Today I tried to
   > delete one of the rows in this table with the following command (worked
   > fine a few weeks ago) and there's the output.
   
   > testsqc=> DELETE FROM henkilo WHERE id = 12;
   > pqReadData() -- backend closed the channel unexpectedly.
   
   Did you rename this table, or another one associated with it via a
   foreign key reference?  If so, undo the rename.  The foreign-key stuff
   doesn't track table renames, and doesn't error out gracefully either :-(
   (the latter bug is fixed for 7.0.3, at least)
   
   			regards, tom lane
   
   

3. Re: backend closed the channel unexpectedly?!?

   Sean Kelly <s.kelly@ncl.ac.uk> — 2000-11-09T16:14:09Z

   On Wed, 08 Nov 2000 16:54:40 +0200, Martti Hertzen said:
   
   >  testsqc=> DELETE FROM henkilo WHERE id = 12;
   >  pqReadData() -- backend closed the channel unexpectedly.
   >          This probably means the backend terminated abnormally
   >          before or while processing the request.
   >  The connection to the server was lost. Attempting reset: Failed.
   >  !>
   >  
   >  Here's the output of the debug channel:
   >  
   >  001108.16:31:16.753 [31195] StartTransactionCommand
   >  001108.16:31:16.753 [31195] query: DELETE FROM henkilo WHERE id = 12;
   >  001108.16:31:16.840 [31195] ProcessQuery
   >  postmaster: reaping dead processes...
   >  postmaster: CleanupProc: pid 31195 exited with status 139
   >  Server process (pid 31195) exited with status 139 at Wed Nov  8 16:31:17
   >  2000
   >  Terminating any active server processes...
   >  Server processes were terminated at Wed Nov  8 16:31:17 2000
   >  Reinitializing shared memory and semaphores
   >  001108.16:31:17.822 [30871] shmem_exit(0)
   >  binding ShmemCreate(key=52e4b5, size=1104896)
   
   	I had this problem after renaming OLD_TABLE to NEW_TABLE
   after creating foreign keys in OLD_TABLE referencing MASTER_TABLE.
   
   	Listen to Tom ... he knows his stuff ;)
   
   -- 
   Sean Kelly <S.Kelly@ncl.ac.uk>
   "If 99% is good enough, then gravity will not work for 14 minutes
    every day."