Re: About large objects asynchronous and non-blocking support

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: g(dot)mascellani(at)gmail(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: About large objects asynchronous and non-blocking support
Date: 2013-06-05 23:20:48
Message-ID: 20130606.082048.998330612674120762.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Hi.
>
> At the moment libpq doesn't seem to support asynchronous and
> non-blocking support for large objects, in the style of
> PQsendQuery/PQgetResult. This makes large objects hardly suited for
> single-threaded programs based on some variant of select().
>
> I would like to know whether this is a deliberate decision or it is
> considered a bug, and, in case, whether it is scheduled to be fixed.

Certainly not bug, since the doc clearly stats that PQsendQuery can
only be used as a substituation of PQexec. (see "Asynchronous Command
Processing" section" for more details). The large object API is
completely different from PQexec and its friends, so it cannot be used
with PQsendQuery.

Talking about more details, PQexec and PQsendQuery is designed to
handle only "Q" messsage out of PostgreSQL frontend/backend protocol,
while to access large objects, you need to handle "V" message.

> Though I cannot guarantee anything, I may be interested into working out
> a patch, if no one is already doing the same (of course I understand
> that this patch wouldn't be for 9.3, which is already in its late
> release cycle).
>
> Do you think this may be of interest?

Yes, I understand your pain, and I myself think we need new APIs for
large objects. Probably that would be not terribly hard. One idea
would be inventing an asynchronous version of PQfn and let
lo_read/lo_write allow to use the new API.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-06-06 00:37:22 Re: Redesigning checkpoint_segments
Previous Message Tom Lane 2013-06-05 22:56:28 Re: MVCC catalog access