Re: backend debug information

Hello Selkovjr and Tom,

Thanks for the assistance in helping me to get into the PostgreSQL development
of my "C" extension functions.

Actually I am moving slowly Selkovjr, as I have entered the "learning-curve" of
PostgreSQL and writing these extension functions but it is always necessary to
slow down as we learn new implementations and familiarizations.

I am actually "multitasking" my work on an entire set of classes that we will
be using in our project and it would be nice to have these functions availiable
in the PostgreSQL command set.

The classes are the "crypto4.0" libraries that feature MANY MANY MANY
encryption/decryption methods such as DES, Blowfish, the RSA suite to include
RC5 and RC6, etc....

It is not that we will actually use all of these in our project but it would be
very nice for PostgreSQL to have all of them availiable I think.

I currently have multiple questions running on the forum right now and am
working to solve them both.

I have gotten the "unixcrypt()" working along with the "DES-Encrypt" functions
to work as well, and am trying to tackle the DES-Decrypt" which should be
working just fine as well because the implementation is very similar to the
Encryption method.

The other set of functions (methods) that I am working on are the RSA
encryption/decryption methods. These should also be very easily implemented,
but it is the "key generation" function that I am having a little trouble with
as it needs a "user data type" similar to the "complex" type but using two
"text" fields instead.

This "RSA key generation" function should allow the user to call the function
from the "psql command interpreter" with something like:

GenerateRSAkey(key_length,seed)

and should return the public and private keys in the user datatype.

The user could then access each field of the datatype to get the actual public
key or private key as needed.

sounds pretty easy, but I am also learning how things work with PostgreSQL as I
go such that things are moving a little slower than I normally do.

I will look over the information that you have sent and look forward to you
future replies to these messages.

Thanks again for all of the help,
Lonnie
--- selkovjr(at)mcs(dot)anl(dot)gov wrote:
>
> 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
>

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/