Re: backend debug information
От | selkovjr@mcs.anl.gov |
---|---|
Тема | Re: backend debug information |
Дата | |
Msg-id | 200104162044.PAA00749@selkovjr.xnet.com обсуждение исходный текст |
Ответ на | backend debug information (Lonnie Cumberland <lonnie_cumberland@yahoo.com>) |
Ответы |
Re: backend debug information
Re: backend debug information |
Список | pgsql-interfaces |
Take it easy, Lonnie! I am still working on your earlier question :) > I am getting this: > trdata=# select desdecrypt('a','b'); > pqReadData() -- backend closed the channel unexpectedly. > This probably means the backend terminated abnormally > before or while processing the request. > The connection to the server was lost. Attempting reset: Failed. > !# \q You've probably got a segv. There's very little else that can happen in your code. That in turn could be caused by writing at an overflown pointer or by returning the wrong type. As far as debugging, short of being able to run a postgres under gdb while connecting clients to it (I wish I knew whether that was at all possible), your options are: 1. (preferred) -- fprintf(stderr, ,) from within your code; then watch the logs or simply start your postmaster from a shell without detaching it and see the output. 2. Make a wrapper that walks like a postgres and talks like a postgres but does nothing except it calls your function and checks the return value; then run that stuff in gdb. As a general rule, 3. Slow down. Proceed in small increments. Start with a blank function and make sure you can pass the desired arguments to it. Return nothing. Check the values you pass with fprintf. Then add a return statement and see if you can get away with it. Check it on the outside with a SELECT. After that, keep adding the code in small logical units. If it breaks, insert fprintf's to see where. Fprintfs are almost as good as debugger breakpoints. I'll be back with more stuff regarding the datatypes shortly. --Gene
В списке pgsql-interfaces по дате отправления: