Fw: 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@amiindia.co.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@amiindia.co.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@fuhr.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