Thread: pqReadData() -- backend closed the channel unexpectedly
I have been using: *RedHat Linux 6.1 [2.2.12-20] on Intel *PostgreSQL 6.5.3-3 [your RPMs] *Perl 5.00503 *Apache 1.3.9 *mod_perl 1.21 *DBI 1.13 *DBD-Pg-0.93 on 2 Intel systems without any problems for several months now, the production website is an SMP box & the development boxis a old, single processor intel. My development box works fine, but when I recently moved the exact same mod_perl scripts over to the production server Ireceived the following error message: "null: DBD::Pg::st execute failed: pqReadData() -- backend closed the channel unexpectedly. This probably means the backendterminated abnormally before or while processing the request. [error] Couldn't execute statement: pqReadData() -- backend closed the channel unexpectedly. This probably means the backendterminated abnormally before or while processing the request. NOTICE: Message from PostgreSQL backend: The Postmaster has informed me that some other backend died abnormally and possiblycorrupted shared memory. I have rolled back the current transaction and am going to terminate your database systemconnection and exit. Please reconnect to the database system and repeat your query." I'm confused. Where do I need to start looking? The script is fine... Thanks! -- BLH www.RentZone.org
On Tue, 19 Sep 2000, Buddy Lee Haystack wrote: > I'm confused. Where do I need to start looking? The script is fine... Best bet is to start by getting the end of the postmaster logs. That'll probably have more information about immediate causes.
Thanks for the quick response!
Here they are, but they seem as vague as the Apache error logs -to me anyway...
FindExec: found "/usr/bin/postgres" using argv[0]
/usr/bin/postmaster: BackendStartup: pid 886 user nobody db rzone socket 4
FindExec: found "/usr/bin/postgres" using argv[0]
started: host=localhost user=nobody database=rzone
InitPostgres
reset_client_encoding()..
reset_client_encoding() done.
StartTransactionCommand
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
ProcessUtility
CommitTransactionCommand
StartTransactionCommand
ProcessQuery
CommitTransactionCommand
/usr/bin/postmaster: BackendStartup: pid 887 user nobody db rzone socket 4
FindExec: found "/usr/bin/postgres" using argv[0]
started: host=localhost user=nobody database=rzone
InitPostgres
reset_client_encoding()..
reset_client_encoding() done.
StartTransactionCommand
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
ProcessUtility
CommitTransactionCommand
StartTransactionCommand
ProcessQuery
CommitTransactionCommand
/usr/bin/postmaster: BackendStartup: pid 888 user nobody db rzone socket 4
FindExec: found "/usr/bin/postgres" using argv[0]
started: host=localhost user=nobody database=rzone
InitPostgres
reset_client_encoding()..
reset_client_encoding() done.
StartTransactionCommand
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
ProcessUtility
CommitTransactionCommand
StartTransactionCommand
ProcessQuery
CommitTransactionCommand
/usr/bin/postmaster: BackendStartup: pid 889 user nobody db rzone socket 4
FindExec: found "/usr/bin/postgres" using argv[0]
started: host=localhost user=nobody database=rzone
InitPostgres
reset_client_encoding()..
reset_client_encoding() done.
StartTransactionCommand
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
ProcessUtility
CommitTransactionCommand
StartTransactionCommand
ProcessQuery
CommitTransactionCommand
/usr/bin/postmaster: BackendStartup: pid 890 user nobody db rzone socket 4
FindExec: found "/usr/bin/postgres" using argv[0]
started: host=localhost user=nobody database=rzone
InitPostgres
reset_client_encoding()..
reset_client_encoding() done.
StartTransactionCommand
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
ProcessUtility
CommitTransactionCommand
StartTransactionCommand
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
ProcessQuery
/usr/bin/postmaster: reaping dead processes...
/usr/bin/postmaster: CleanupProc: pid 888 exited with status 139
/usr/bin/postmaster: CleanupProc: sending SIGUSR1 to process 890
/usr/bin/postmaster: CleanupProc: sending SIGUSR1 to process 889
/usr/bin/postmaster: CleanupProc: sending SIGUSR1 to process 887
NOTICE: Message from PostgreSQL backend:
The Postmaster has informed me that some other backend died abnormally and
possibly corrupted shared memory.
I have rolled back the current transaction and am going to terminate your
database system connection and exit.
Please reconnect to the database system and repeat your query.
NOTICE: Message from PostgreSQL backend:
The Postmaster has informed me that some other backend died abnormally and
possibly corrupted shared memory.
I have rolled back the current transaction and am going to terminate your
database system connection and exit.
Please reconnect to the database system and repeat your query.
/usr/bin/postmaster: CleanupProc: sending SIGUSR1 to process 886
NOTICE: Message from PostgreSQL backend:
The Postmaster has informed me that some other backend died abnormally and
possibly corrupted shared memory.
I have rolled back the current transaction and am going to terminate your
database system connection and exit.
Please reconnect to the database system and repeat your query.
/usr/bin/postmaster: CleanupProc: reinitializing shared memory and semaphores
shmem_exit(0) [#0]
NOTICE: Message from PostgreSQL backend:
The Postmaster has informed me that some other backend died abnormally and
possibly corrupted shared memory.
I have rolled back the current transaction and am going to terminate your
database system connection and exit.
Please reconnect to the database system and repeat your query.
/usr/bin/postmaster: CleanupProc: pid 890 exited with status 0
/usr/bin/postmaster: CleanupProc: pid 889 exited with status 0
/usr/bin/postmaster: CleanupProc: pid 887 exited with status 0
/usr/bin/postmaster: CleanupProc: pid 886 exited with status 0
/usr/bin/postmaster: reaping dead processes...
/usr/bin/postmaster: BackendStartup: pid 901 user nobody db rzone socket 4
FindExec: found "/usr/bin/postgres" using argv[0]
started: host=localhost user=nobody database=rzone
InitPostgres
reset_client_encoding()..
reset_client_encoding() done.
StartTransactionCommand
ProcessUtility
CommitTransactionCommand
StartTransactionCommand
ProcessQuery
/usr/bin/postmaster: reaping dead processes...
/usr/bin/postmaster: CleanupProc: pid 901 exited with status 139
/usr/bin/postmaster: CleanupProc: reinitializing shared memory and semaphores
shmem_exit(0) [#0]
Stephan Szabo wrote:
> Best bet is to start by getting the end of the postmaster logs. That'll
> probably have more information about immediate causes.
--
BLH
www.RentZone.org
> /usr/bin/postmaster: CleanupProc: pid 888 exited with status 139 Okay, we have a postgres process going down with a SEGV. Do you have a core file? I don't quite remember where they end up, but my guess would be either the directory with postgres or somewhere in the data directory (probably the directory for the db). Next step is to try to get a backtrace from the core.
Buddy Lee Haystack <haystack@email.rentzone.org> writes:
> Here they are, but they seem as vague as the Apache error logs -to me anyway...
You're right, not much info there except that a backend died untimely.
Unless you had ulimit set to prevent it, the crashing backend should've
left a core file in the database subdirectory it was connected to (ie,
$PGDATA/base/DATABASENAME/core). If so, it'd be useful to see a stack
trace from that file ... do you know how to get a stack trace with gdb?
Copy the corefile to someplace safe, in any case; we may want to
study it later.
One thing that would be real helpful to know is exactly what query the
failed backend was trying to execute. Perhaps you know that already.
If not, but if you can reproduce the crash by rerunning your
application, then restart the postmaster with "-d2" added to its command
line arguments; that will cause each backend to log each query it
executes.
regards, tom lane
Tom Lane wrote:
> You're right, not much info there except that a backend died untimely.
>
> Unless you had ulimit set to prevent it, the crashing backend should've
> left a core file in the database subdirectory it was connected to (ie,
> $PGDATA/base/DATABASENAME/core). If so, it'd be useful to see a stack
> trace from that file ... do you know how to get a stack trace with gdb?
> Copy the corefile to someplace safe, in any case; we may want to
> study it later.
Thanks!
Sorry for my delays in responding, but I'm wearing many hats this week.:)
Here's the program stack of the core file using gdb [I learn something new every day!]:
[root@email /root]# gdb -core=/coredump/core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux".
Core was generated by `/usr/bin/postgres localhos'.
Program terminated with signal 11, Segmentation fault.
#0 0x8096243 in ?? ()
(gdb) bt
#0 0x8096243 in ?? ()
#1 0x8092f3e in ?? ()
#2 0x8092279 in ?? ()
#3 0x809197e in ?? ()
#4 0x80e0568 in ?? ()
#5 0x80e05ce in ?? ()
#6 0x80df008 in ?? ()
#7 0x80deee7 in ?? ()
#8 0x80dff88 in ?? ()
#9 0x80c9c8a in ?? ()
#10 0x80c97ac in ?? ()
#11 0x80c8ef9 in ?? ()
#12 0x80c8a3c in ?? ()
#13 0x80a0fcd in ?? ()
#14 0x401039cb in ?? ()
(gdb) quit
[root@email /root]#
> One thing that would be real helpful to know is exactly what query the
> failed backend was trying to execute. Perhaps you know that already.
I think its choking on the the first, simplest query I've written "$sql11 = 'select count(1) from rzlist where
rzactive=1';"
if (! defined $dbh) {
$dbh = DBI->connect("dbi:Pg:dbname=rzone")
or die "Couldn't connect to database: " . DBI->errstr;
}
my($sql11,$sth11);
if (! defined $sth11) {
$sql11 = 'select count(1) from rzlist where rzactive =1';
$sth11 = $dbh->prepare($sql11)
or die "Couldn't prepare statement: " . $dbh->errstr;
}
$sth11->execute()
or die "Couldn't execute statement: " . $sth11->errstr;
my $HOWMANY = $sth11->fetchrow_array();
$sth11->finish;
######## Query number 2
my $sql= 'SELECT SORR,HORA,RZEMAIL,RZAC,RZX,RZTY,RZTA,RZZIP,
RZADR,RZTR,RZBT,RZBD,RZP,RZA,RZMU,RZMM,RZOLD,RZTAX,RZLU,RZPET,RZHA,
RZMT,RZDT,RZDATIME
FROM RZLIST
WHERE RZACTIVE =1';
if (param('RZZIP')) {$I_RZZIP = &CLEANUP_INTEGERS(param('RZZIP')); $sql .= " and RZZIP like '$I_RZZIP%'";}
if (param('RAC')) {$I_RAC = &CLEANUP_INTEGERS(param('RAC')); $sql .= " and RZAC = '$I_RAC'";}
if (param('RTA')) {$I_RTA = &UPPERCASE(param('RTA')); $sql .= " and RZTA = '$I_RTA' ";}
if (param('RTY')) {$I_RTY = &CITYLOOKUP(param('RTY')); $sql .= " and RZTY like '%$I_RTY%' ";}
if (param('I_SORR') <3) {$I_SORR = &CLEANUP_INTEGERS(param('I_SORR')); $sql .= " and SORR = '$I_SORR'";}
if (param('I_HORA') < 3) {$I_HORA = &CLEANUP_INTEGERS(param('I_HORA')); $sql .= " and HORA = '$I_HORA'";}
if (param('NO_RTR') == 1) {$I_RTR = &CLEANUP_INTEGERS(param('RTR')); $sql .= " and RZTR >= '$I_RTR'";}elsif
(param('NO_RTR') == 2) {$I_RTR = &CLEANUP_INTEGERS(param('RTR')); $sql .= " and RZTR <= '$I_RTR'";}elsif
(param('NO_RTR') == 3) {$I_RTR = &CLEANUP_INTEGERS(param('RTR')); $sql .= " and RZTR = '$I_RTR'";}
if (param('NO_RBT') == 1) {$I_RBT = &CLEANUP_INTEGERS(param('RBT')); $sql .= " and RZBT >= '$I_RBT'";}elsif
(param('NO_RBT') == 2) {$I_RBT = &CLEANUP_INTEGERS(param('RBT')); $sql .= " and RZBT <= '$I_RBT'";}elsif
(param('NO_RBT') == 3) {$I_RBT = &CLEANUP_INTEGERS(param('RBT')); $sql .= " and RZBT = '$I_RBT'";}
if (param('NO_RBD') == 1) {$I_RBD = &CLEANUP_INTEGERS(param('RBD')); $sql .= " and RZBD >= '$I_RBD'";}elsif
(param('NO_RBD') == 2) {$I_RBD = &CLEANUP_INTEGERS(param('RBD')); $sql .= " and RZBD <= '$I_RBD'";}elsif
(param('NO_RBD') == 3) {$I_RBD = &CLEANUP_INTEGERS(param('RBD')); $sql .= " and RZBD = '$I_RBD'";}
$sql .= " order by SORR,HORA,RZTR,RZTA,RZZIP,RZAC";
my $sth = $dbh->prepare($sql)
or die "Couldn't prepare statement: " . $dbh->errstr;
$sth->execute()
or die "Couldn't execute statement: " . $sth->errstr;
my $rv = $sth->bind_columns(\$O_SORR,\$O_HORA,\$O_RZEMAIL,\$O_RZAC,
\$O_RZX,\$O_RZTY,\$O_RZTA,\$O_RZZIP,\$O_RZADR,\$O_RZTR,\$O_RZBT,\$O_RZBD,\$O_RZP,\$O_RZA,
\$O_RZMU,\$O_RZMM,\$O_RZOLD,\$O_RZTAX,\$O_RZLU,\$O_RZPET,\$O_RZHA,\$O_RZMT,\$O_RZDT,
\$O_RZDATIME);
> If not, but if you can reproduce the crash by rerunning your
> application, then restart the postmaster with "-d2" added to its command
> line arguments; that will cause each backend to log each query it
> executes.
After issuing:
"postmaster -d2> pgserver.log 2>&1 &"
and trying to run any mod_perl script connecting to a databse I'm greated with a connect
DB error that questions if postmaster is running on port.... It is...
I normally use:
"postmaster -d> pgserver.log 2>&1 &"
which works fine, but...
>
> regards, tom lane
Thanks again!
--
BLH
www.RentZone.org
Buddy Lee Haystack <haystack@email.rentzone.org> writes:
> Here's the program stack of the core file using gdb [I learn something new every day!]:
> (gdb) bt
> #0 0x8096243 in ?? ()
> #1 0x8092f3e in ?? ()
> #2 0x8092279 in ?? ()
> #3 0x809197e in ?? ()
Not much help there :-(. Can you recompile with -g and try it again?
regards, tom lane
I just sent this, but in reply to a thread that ended in "unexp"; consequently, it went to a different place. Houston, we've got a problem with SMP boxes... I commented out the first simple query that counted records in the database at script startup, and the problems disappeared.I "THINK" the threading was closing the statement handle before the results of the query were returned to themod_perl scripts on the SMP box. The SMP box was a bit too fast! I'd like to reiterate that I have the same, IDENTICAL software on 2 systems [every singlesoftware package & patch]. No problems on the 4.5 year old single processor Intel box I use for development. For now,I'll run the scaled down version on the production box, but this issue should be addressed. I can't be the only personwith this issue. Thanks! Tom Lane wrote: > > Buddy Lee Haystack <haystack@email.rentzone.org> writes: > > Here's the program stack of the core file using gdb [I learn something new every day!]: > > > (gdb) bt > > #0 0x8096243 in ?? () > > #1 0x8092f3e in ?? () > > #2 0x8092279 in ?? () > > #3 0x809197e in ?? () > > Not much help there :-(. Can you recompile with -g and try it again? > > regards, tom lane -- BLH www.RentZone.org
- Hello - I have looked for a data type which allows me to have (using a cliche example again) FlightDetail_Arrival whcih is like so 21:07:00 18:00 - When I type this in psql it changes my data type from datetime to "timestamp" - It gives me the following about I did a SELECT * FROM table - 21:07:00 18:00 + 11 - Question 1) How to i make the datatype to just "21:07:00 18:00" only Lookinf gowrd to your feedback. dannyh@idx.com.au On Wed, 20 Sep 2000, Tom Lane wrote: > Buddy Lee Haystack <haystack@email.rentzone.org> writes: > > Here they are, but they seem as vague as the Apache error logs -to me anyway... > > You're right, not much info there except that a backend died untimely. > > Unless you had ulimit set to prevent it, the crashing backend should've > left a core file in the database subdirectory it was connected to (ie, > $PGDATA/base/DATABASENAME/core). If so, it'd be useful to see a stack > trace from that file ... do you know how to get a stack trace with gdb? > Copy the corefile to someplace safe, in any case; we may want to > study it later. > > One thing that would be real helpful to know is exactly what query the > failed backend was trying to execute. Perhaps you know that already. > If not, but if you can reproduce the crash by rerunning your > application, then restart the postmaster with "-d2" added to its command > line arguments; that will cause each backend to log each query it > executes. > > regards, tom lane