Re: How to code lo_creat & lo_write & lo_read in non-blocking mode - Mailing list pgsql-general

From ChoonSoo Park
Subject Re: How to code lo_creat & lo_write & lo_read in non-blocking mode
Date
Msg-id CACgbiFvT5a+66d7P26TprY5Y75DC7vfEhvHZkUaGzX_t_pi8Ow@mail.gmail.com
Whole thread Raw
In response to Re: How to code lo_creat & lo_write & lo_read in non-blocking mode  (Dmitriy Igrishin <dmitigr@gmail.com>)
List pgsql-general
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).

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.



pgsql-general by date:

Previous
From: Radosław Smogura
Date:
Subject: Re: Vacuum and Large Objects
Next
From: Neil Tiffin
Date:
Subject: Re: Supporting SQL/MED DATALINK