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
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 |