Re: libpq lo_open errors when first action in connection

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Greg Sabino Mullane" <greg(at)turnstep(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: libpq lo_open errors when first action in connection
Date: 2005-05-13 03:37:18
Message-ID: 19637.1115955438@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Greg Sabino Mullane" <greg(at)turnstep(dot)com> writes:
> I'm having some problems with lo_open inside of DBD::Pg (which
> uses libpq) and need help in debugging the problem.

lo_open doesn't work unless inside a transaction block (and even
if it did work, the result would be useless to you).

I believe the reason for the -1 result is this code inside libpq's
lo_open:

/* 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;

Since you forgot to start a transaction block, the results of the
backend lo_open call are already dead and the lo_lseek fails with
ERROR: invalid large-object descriptor: 0

This looks rather considerably like a hack to compensate for a very
long-gone bug ... can anyone see a reason not to take it out?
Of course taking it out wouldn't improve Greg's results much, since
he'd still get a failure at the next LO operation, but this sure
looks like it's incurring a useless network round trip...

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-05-13 05:15:36 Re: SQL_ASCII vs. 7-bit ASCII encodings
Previous Message Christopher Kings-Lynne 2005-05-13 03:27:35 Re: PostgreSQL running out of file handles