Exporting closePGconn from libpq

Поиск
Список
Период
Сортировка
От Leon Smith
Тема Exporting closePGconn from libpq
Дата
Msg-id BANLkTi=qkJg0EvYcn1jYUhP5F1pwhYUWRw@mail.gmail.com
обсуждение исходный текст
Ответы Re: Exporting closePGconn from libpq
Re: Exporting closePGconn from libpq
Re: Exporting closePGconn from libpq
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Reducing overhead of frequent table locks
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Exporting closePGconn from libpq