Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4
От | Tom Lane |
---|---|
Тема | Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4 |
Дата | |
Msg-id | 24618.1247500046@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4 (Frank van Vugt <ftm.van.vugt@foxi.nl>) |
Ответы |
Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4
|
Список | 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 по дате отправления: