Re: pqReadData() -- backend closed the channel unexpectedly - Mailing list pgsql-general

From Buddy Lee Haystack
Subject Re: pqReadData() -- backend closed the channel unexpectedly
Date
Msg-id 39C8D5AE.6955217F@email.rentzone.org
Whole thread Raw
In response to Re: pqReadData() -- backend closed the channel unexpectedly  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
Responses Re: pqReadData() -- backend closed the channel unexpectedly  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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@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

pgsql-general by date:

Previous
From: The Hermit Hacker
Date:
Subject: RE: WTF is going on with PG_VERSION?
Next
From: Dave Hollenbeck
Date:
Subject: arrays and subselects