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
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 |