Re: How to code lo_creat & lo_write & lo_read in non-blocking mode

Dmitriy,

I have been building an executable c++ program that uses Postgresql C
(libpq) API. All SQL statements were designed to be executed in
non-blocking mode and it works fine with postgresql non-blocking interface.
I also wanted to handle blob files in non-blocking mode as well.

The size of the blob file (to be inserted) could be from 1M to 1G. If I
have to rely on blocking interface, then the current linux process will be
blocked by this blob upload operation.
(Current project I'm working on doesn't allow multi-threaded applications.
We have to implement a single-threaded processes.)

This is why I have been trying to find a way to execute blob save/retrieval
operation in non-blocking mode.

Thank you,
Choon Park

On Sat, Jan 7, 2012 at 5:05 AM, Dmitriy Igrishin <dmitigr(at)gmail(dot)com> wrote:

> Hey ChoonSoo,
>
> 2012/1/6 ChoonSoo Park <luispark(at)gmail(dot)com>
>
>> I just wonder if there is a way to program lo client interfaces
>> (lo_creat, lo_write, lo_read) in non-blocking mode.
>> PQsendQueryParams works perfect for executing a sql command in
>> non-blocking mode. But I couldn't find a way for handling large objects.
>>
> These functions uses obsolete fast-path interface to call
> these functions on the backend:
> dmitigr=> select oid, proname from pg_proc where proname ~ E'^lo_' or
> proname in ('loread', 'lowrite');
> oid | proname
> ------+-------------
> 764 | lo_import
> 767 | lo_import
> 765 | lo_export
> 952 | lo_open
> 953 | lo_close
> 954 | loread
> 955 | lowrite
> 956 | lo_lseek
> 957 | lo_creat
> 715 | lo_create
> 958 | lo_tell
> 1004 | lo_truncate
> 964 | lo_unlink
> (13 rows)
>
> So, you can call these functions using regular SQL
> (prepared statements may be used for improving
> performance in this case).
>
>>
>> Do you have any example?
>>
> I can't imagine how (and why) to work with LOs
> in asynchronous mode because LOs stored as a
> sequence of chunks (the size is usually 4kb)
> of the type bytea in the special table. As consequence all
> operations on the LOs must be inside an explicitly opened
> transaction block.
>
>>
>> Thank you,
>> Choon Park
>>
>
>
>
> --
> // Dmitriy.
>
>
>