Re: [ADMIN] Reg:lo_open error..pls help me

Hi,

In my application i need to create a file dynamically and load it into DB.

So.....I have created one object at run time .....and trying to open it inorder to write the content into it.....
But lo_open is returning -1(-ve value).
where i am doing mistake pls tell me.

lobjId = lo_creat(conn, INV_READ | INV_WRITE);
if (lobjId == 0)
fprintf(stderr, "can't create large object\n");

lobj_fd = lo_open(conn, lobjId, INV_WRITE);
//My application failed at this point..what i am missing here ?
if (lobj_fd < 0)
{
fprintf(stderr, "can't open large object %d\n",lobjId);
}
lo_lseek(conn, lobj_fd, 0, SEEK_SET);
nwritten = 0;
len = strlen(szContent);
while (len - nwritten > 0)
{
nbytes = lo_write(conn, lobj_fd, szContent, len - nwritten);
nwritten += nbytes;
}

Is it possible to use lo_open after creating the object while the application is running?
Hi,
In my application i need to create a file dynamically and load it into DB.

So.....I have created one object at run time .....and trying to open it inorder to write the content into it.....
But lo_open is returning -1(-ve value).
where i am doing mistake pls tell me.

lobjId = lo_creat(conn, INV_READ | INV_WRITE);
if (lobjId == 0)
fprintf(stderr, "can't create large object\n");

lobj_fd = lo_open(conn, lobjId, INV_WRITE);
//My application failed at this point..what i am missing here ?
if (lobj_fd < 0)
{
fprintf(stderr, "can't open large object %d\n",lobjId);
}
lo_lseek(conn, lobj_fd, 0, SEEK_SET);
nwritten = 0;
len = strlen(szContent);
while (len - nwritten > 0)
{
nbytes = lo_write(conn, lobj_fd, szContent, len - nwritten);
nwritten += nbytes;
}

On Wed, Mar 01, 2006 at 05:48:51PM +0530, sandhya wrote:
> Is it possible to use lo_open after creating the object while
> the application is running?

Yes, but that's off-topic for pgsql-admin. Try pgsql-interfaces
or pgsql-general.

--
Michael Fuhr

"sandhya" <sandhyar(at)amiindia(dot)co(dot)in> writes:
> But lo_open is returning -1(-ve value).

Are you sure that's where it's failing? The fragment you showed looks
fine as far as it goes. The most likely bet is you forgot to wrap it in
a transaction (BEGIN/COMMIT commands), but that would result in a
failure at the seek/write commands because the object wouldn't be open
anymore.

You might want to look at src/test/examples/testlo.c in the PG distribution.

regards, tom lane

On Wed, Mar 01, 2006 at 11:03:12AM -0500, Tom Lane wrote:
> "sandhya" <sandhyar(at)amiindia(dot)co(dot)in> writes:
> > But lo_open is returning -1(-ve value).
>
> Are you sure that's where it's failing? The fragment you showed looks
> fine as far as it goes. The most likely bet is you forgot to wrap it in
> a transaction (BEGIN/COMMIT commands), but that would result in a
> failure at the seek/write commands because the object wouldn't be open
> anymore.

lo_open() fails if it's not in a transaction. The error from
PQerrorMessage is:

ERROR: invalid large-object descriptor: 0

--
Michael Fuhr

Michael Fuhr <mike(at)fuhr(dot)org> writes:
> On Wed, Mar 01, 2006 at 11:03:12AM -0500, Tom Lane wrote:
>> Are you sure that's where it's failing? The fragment you showed looks
>> fine as far as it goes. The most likely bet is you forgot to wrap it in
>> a transaction (BEGIN/COMMIT commands), but that would result in a
>> failure at the seek/write commands because the object wouldn't be open
>> anymore.

> lo_open() fails if it's not in a transaction. The error from
> PQerrorMessage is:
> ERROR: invalid large-object descriptor: 0

Hmm, I wonder why that is [ looks at code ... ]

The culprit seems to be this little bit in libpq's lo_open() function:

/* have to do this to reset offset in shared fd cache */
/* but only if fd is valid */
if (fd >= 0 && lo_lseek(conn, fd, 0L, SEEK_SET) < 0)
return -1;
return fd;

Outside a transaction block, this fails since the LO FD is already
closed by the time the lo_lseek request is run.

This hack goes all the way back --- it's in our original CVS version,
and there is equivalent code in Postgres v4r2 --- but it sure looks to
me like a workaround for a long-forgotten bug. It's forcing an extra
network round trip for every lo_open, so I'm very strongly tempted to
remove it. Comments?

regards, tom lane