| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl> |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4 |
| Date: | 2009-07-13 15:47:26 |
| Message-ID: | 24618.1247500046@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Kerr | 2009-07-13 16:17:49 | Re: BUG #4914: uuid_generate_v4 not present in eithersource or yum/rpm |
| Previous Message | Frank van Vugt | 2009-07-13 15:37:51 | Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4 |