From: | Leon Smith <leon(dot)p(dot)smith(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Exporting closePGconn from libpq |
Date: | 2011-05-14 15:23:13 |
Message-ID: | BANLkTi=qkJg0EvYcn1jYUhP5F1pwhYUWRw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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.
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.
Is there any particular reason why closePGconn should not be exported
from libpq?
Best,
Leon
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-05-14 15:37:41 | Re: Exporting closePGconn from libpq |
Previous Message | Tom Lane | 2011-05-14 15:14:27 | Re: Reducing overhead of frequent table locks |