Michael Fuhr <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
