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@gmail.com> wrote:
Hey ChoonSoo,
2012/1/6 ChoonSoo Park
<luispark@gmail.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).
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.
--
// Dmitriy.