On Sat, May 14, 2011 at 11:23 AM, Leon Smith <leon.p.sm...@gmail.com> wrote: > A minor issue has come up in creating low-level bindings to libpq for > safe garbage-collected languages, namely that PQfinish is the only > (AFAICT) way to close a connection but also de-allocates the memory > used to represent the database connection. It would be preferable > to call PQfinish to free the memory in a finalizer, but appilcations > need a way to disconnect from the database at a predictable and > deterministic point in time, whereas leaving a bit of memory around > until the GC finally gets to it is relatively harmless. The > low-level binding has a couple of options: > > 1. Ignore the issue and allow for the possibility of a segfault if > the library is used incorrectly, which is not a good situation for > "safe" languages.
The 'safety' of the language has nothing to do with it. It should possible to maintain state outside of libpq without crashing. Which language by the way? > 2. Create a wrapper that tracks whether or not PQfinish has ever been > called, so that attempts to use a connection afterwards can be turned > into native exceptions/other forms of error signaling. This kind of > solution can introduce their own minor issues. This is probably your answer. > 3. Hack libpq to export closePGconn so that libpq can safely signal > the low-level bindings of the error when a connection is used after it > is disconnected, reserving PQfinish to run in a GC-triggered > finalizer. While this is a technically preferable solution, without > getting the change into upstream sources it is also a deployment > nightmare. This is not going to be as helpful as you think -- in many cases the connection will not go 'bad' until you attempt to use...libpq runs in thread and does no management when you are not inside a libpq call. Your hypothetical callback would only get fired when you are making a libpq call anyways and you haven't made a case why you can't just wrap the query call with a a post call check to connection status. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers