Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4
Date
Msg-id 24618.1247500046@sss.pgh.pa.us
Whole thread Raw
In response to Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4  (Frank van Vugt <ftm.van.vugt@foxi.nl>)
Responses Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4  (Frank van Vugt <ftm.van.vugt@foxi.nl>)
List pgsql-bugs
Frank van Vugt <ftm.van.vugt@foxi.nl> writes:
> Just fyi, a breakpoint at SPI_connect with condition
>     _SPI_curid != _SPI_connected

Right, that's what to look for.

> produced the following backtrace:

> Program received signal SIGUSR2, User defined signal 2.
> 0x00002b539af2b5f5 in recv () from /lib64/libc.so.6
> (gdb) bt
> #0  0x00002b539af2b5f5 in recv () from /lib64/libc.so.6
> #1  0x000000000054d692 in secure_read ()
> #2  0x0000000000552c74 in pq_recvbuf ()
> #3  0x0000000000553077 in pq_getbyte ()
> #4  0x00000000005ce5f6 in PostgresMain ()
> #5  0x00000000005a50fb in ServerLoop ()
> #6  0x00000000005a5c2a in PostmasterMain ()
> #7  0x000000000055498e in main ()

This is a normal interbackend communication signal.  You need to
configure gdb to ignore SIGUSR2 (ie, pass it on and not stop execution).
Probably SIGUSR1 too.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Frank van Vugt
Date:
Subject: Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4
Next
From: David Kerr
Date:
Subject: Re: BUG #4914: uuid_generate_v4 not present in eithersource or yum/rpm