Обсуждение: libpq thread safety

Поиск
Список
Период
Сортировка

libpq thread safety

От
Mark Morgan Lloyd
Дата:
Do any special precautions need to be taken when PQNotifies is being
called, to make sure that nothing else is referencing the handle?

The sort of nightmare scenario I'm thinking about is when a background
thread is periodically pulling data from a table into a buffer, but a
foreground (GUI) timer is asynchronously polling for notifications.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]


Re: libpq thread safety

От
Tom Lane
Дата:
Mark Morgan Lloyd <markMLl.pgsql-general@telemetry.co.uk> writes:
> Do any special precautions need to be taken when PQNotifies is being
> called, to make sure that nothing else is referencing the handle?

It's pretty much the same as any other operation on a PGconn: if there
could be more than one thread touching the connection object
concurrently, you'd be well advised to add some application-level
locking.

http://www.postgresql.org/docs/9.2/static/libpq-threading.html

The lack of any such locking inside libpq is partly historical, and
partly because in many practical situations you'll need application-side
locks anyway to protect application data structures associated with the
connection.

            regards, tom lane


Re: libpq thread safety

От
Mark Morgan Lloyd
Дата:
Tom Lane wrote:
> Mark Morgan Lloyd <markMLl.pgsql-general@telemetry.co.uk> writes:
>> Do any special precautions need to be taken when PQNotifies is being
>> called, to make sure that nothing else is referencing the handle?
>
> It's pretty much the same as any other operation on a PGconn: if there
> could be more than one thread touching the connection object
> concurrently, you'd be well advised to add some application-level
> locking.
>
> http://www.postgresql.org/docs/9.2/static/libpq-threading.html
>
> The lack of any such locking inside libpq is partly historical, and
> partly because in many practical situations you'll need application-side
> locks anyway to protect application data structures associated with the
> connection.

Thanks, Tom. I'm fairly happy with the ways I've used it so far, but I'm
just trying to think ahead for the future.

In the case of Delphi/Lazarus, where you can have multiple queries on
top of the same connection object, my experience so far is that using
the connection object's handle is safe. But I think that to be
absolutely confident of that I need to do some tracing, and find out
under what circumstance calls are being issued directly against that
handle rather than it just being a placeholder for authentication etc.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]