Re: pqReadData() -- backend closed the channel unexpectedly

From: Buddy Lee Haystack <haystack(at)email(dot)rentzone(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: pqReadData() -- backend closed the channel unexpectedly
Date: 2000-09-20 15:20:14
Message-ID: 39C8D5AE.6955217F@email.rentzone.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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(at)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(at)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Fernando Lozano 2000-09-20 15:24:29 import CVS file
Previous Message Dave Hollenbeck 2000-09-20 15:14:21 arrays and subselects