From: | Frank van Vugt <ftm(dot)van(dot)vugt(at)foxi(dot)nl> |
---|---|
To: | Marek Lewczuk <marek(at)lewczuk(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4 |
Date: | 2009-07-14 13:18:15 |
Message-ID: | 200907141518.16021.ftm.van.vugt@foxi.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi Marek,
> Could you please send me gdb
> commands - I could also provide the backtrace
Basically the flow is as follows:
- identify the backend that you expect to run in to this error by pid
- start gdb with the option "-p <pid>" to attach to this backend
- set a conditional breakpoint:
break SPI_connect if _SPI_curid != _SPI_connected
gdb should confirm this with something like Breakpoint 1 at 0x54af60
- tell gdb to ignore SIGUSR1:
handle SIGUSR1 nostop
gdb should confirm this with something like:
Signal Stop Print Pass to program Description
SIGUSR1 No Yes Yes User defined signal 1
- tell gdb to ignore SIGUSR2:
handle SIGUSR2 nostop
gdb should confirm this with something like:
Signal Stop Print Pass to program Description
SIGUSR2 No Yes Yes User defined signal 2
- type 'c' to allow the backend to continue
- reproduce the problem in your application, the moment you do it will seem to
'freeze' (so you will _not_ see any error message you usually were seeing, at
least not yet), because gdb will have catched the situation and should now
show a prompt again
- type 'bt' to get a backtrace, just copy&paste&post ;)
You can quit gdb by a plain <ctrl>-c, just confirm when it asks you to detach.
The backend will continue to run, your app should now show the error.
--
Best,
Frank.
From | Date | Subject | |
---|---|---|---|
Next Message | Marek Lewczuk | 2009-07-14 13:24:54 | Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4 |
Previous Message | Marek Lewczuk | 2009-07-14 12:54:12 | Re: SPI_ERROR_CONNECT within pl/pgsql, PG 8.4 |