Skip site navigation (1) Skip section navigation (2)

Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4

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 (view raw or flat)
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

In response to

Responses

pgsql-bugs by date

Next:From: David KerrDate: 2009-07-13 16:17:49
Subject: Re: BUG #4914: uuid_generate_v4 not present in eithersource or yum/rpm
Previous:From: Frank van VugtDate: 2009-07-13 15:37:51
Subject: Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group