Return-Path: postarch
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA18037; Wed, 11 Dec 91 16:21:14 -0800
Message-Id: <9112120021.AA18037@postgres.Berkeley.EDU>
From: postarch (Postgres Mailing Archive)
Subject: Re: Using inheritance & exceptions
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
Reply-To: mer@postgres.berkeley.edu
In-Reply-To: Your message of "Tue, 03 Dec 91 07:22:29 PST."
             <9112031522.AA10253@postgres.Berkeley.EDU> 
Date: Wed, 11 Dec 91 16:19:13 PST

you write:
> 
> Applications I'm developing use XView (the X toolkit) which crashed
> with a "File descriptor closed" message after I had PQexec'd
> code with a syntax error in. Unfortunately, this looks like a conflict between
> XView and libpq's exception handling which makes use of longjmp.
> XView seems to want to be on top all the time and the "Xview
> Programming Manual" warns against using longjmp and pretty much
> anything to do with Unix signals except through its library interface.
> I have a gentle plea to library designers to watch out for these
> areas (I encountered a similar problem with commercial Ingres).

None of the code that comprises libpq uses setjmp, longjmp or relies on
unix signals.  These are exploited in the backend, but that is of course
an entirely different process and won't affect the goings on in XView.

> I want to be able to keep applications working in the face of any DBMS
> errors, is there anything else I should do apart from checking for an
> "R" status from PQexec?

You might consider modifying the libpq code slightly.  As of now, if it
reads garbage on the line or gets nothing back from the backend it will exit.
When the backend crashes one of these two events are the only possible
occurrences.  It might be more useful to you if you changed things so that it
would set up another connection to another backend giving the application
the appearance of a failed query or an aborted transaction.


Jeff Meredith
mer@postgres.berkeley.edu