From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Leon Smith <leon(dot)p(dot)smith(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Exporting closePGconn from libpq |
Date: | 2011-05-16 12:16:51 |
Message-ID: | BANLkTimQCg_jp0o1D7pNLFt-aMLg52RYgA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, May 14, 2011 at 11:23 AM, Leon Smith <leon(dot)p(dot)smith(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-05-16 13:45:14 | Re: Extensions in schemas |
Previous Message | Markus Wanner | 2011-05-16 08:46:26 | Re: Exporting closePGconn from libpq |