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

Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4

From: Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl>
To: pgsql-bugs(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4
Date: 2009-07-13 15:37:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Hi Tom,

Op maandag 13 juli 2009, schreef Tom Lane:
> Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl> writes:
> > Any clues as to how to gather additional information that might bring us
> > closer to a solution is appreciated also.
> A stack trace from the point of the error would probably tell us a great
> deal.  Maybe you could attach to a backend with gdb, set a breakpoint
> at the failure return in SPI_connect(), and then provoke the error
> manually?

Just fyi, a breakpoint at SPI_connect with condition
	_SPI_curid != _SPI_connected

produced the following backtrace:

Program received signal SIGUSR2, User defined signal 2.
0x00002b539af2b5f5 in recv () from /lib64/
(gdb) bt
#0  0x00002b539af2b5f5 in recv () from /lib64/
#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 ()

However, after continuing this did NOT give the SPI_connect error message, so 
this probably is about something else completely?

We cannot reproduce the error anymore due to end of working hours, will try 
again tomorrow morning (localtime).

More to follow.



In response to


pgsql-bugs by date

Next:From: Tom LaneDate: 2009-07-13 15:47:26
Subject: Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4
Previous:From: Tom LaneDate: 2009-07-13 14:26:08
Subject: Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4

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