From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Ron Snyder <snyder(at)roguewave(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org, "'pgsql-jdbc(at)postgresql(dot)org'" <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Logging function calls to figure out lo_close log entries? |
Date: | 2002-05-08 05:26:10 |
Message-ID: | 29475.1020835570@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-jdbc |
Ron Snyder <snyder(at)roguewave(dot)com> writes:
> May 7 09:40:08 vault pgqv[13698]: [362] ERROR: lo_close: invalid large obj
> descriptor (0)
This generally suggests that someone is trying to use a LO handle beyond
the end of the transaction in which they did lo_open() --- or more to
the point, they forgot to wrap usage of the handle in a begin/commit
transaction block. But I'm not enough of a JDBC user to be sure what
that translates to on the JDBC side.
> I was wondering if there is anything on the server end that I could
> change to help them track this down.
Turn up the debug level? AFAICT your log includes only some of the
queries that are relevant. Could their application be deliberately
suppressing query log entries, perhaps via PGOPTIONS?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Holger Marzen | 2002-05-08 07:05:50 | Re: Performance issues with compaq server |
Previous Message | Tom Lane | 2002-05-08 04:33:55 | Re: How can I speed up this search? |
From | Date | Subject | |
---|---|---|---|
Next Message | Paul Meigniez | 2002-05-08 07:07:21 | NullPointerException in rg.postgresql.jdbc2.ResultSet.getBytes |
Previous Message | Ron Snyder | 2002-05-08 02:08:21 | Logging function calls to figure out lo_close log entries? |