Hi Tom,
Op maandag 13 juli 2009, schreef Tom Lane:
> Frank van Vugt <ftm.van.vugt@foxi.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/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 ()
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.
--
Best,
Frank.