Re: wrong documentation and others .....

Response to late, sorry but I am going out.

Peter Mount escribió:

> I've some experience of Solaris, and now I'm back at work I've got access to
> a few Solaris boxes.
>
> Anyhow, catching up with this thread:
>
> * the fail is in the loop reading the result:
> sometime a 'E' element is return after a 'Z'
>
> This is a protocol problem, and it would be useful to know if it happens
> outside of jdbc. psql won't do in this case, as lo_import() runs locally not
> over the network.
>

The error appear also in linux with RedHat 6.2 and postgresql 7.0.2
I'm using the example from psql:

insert into tbl_objectshelf values
('39',lo_import('/etc/inittab'));
with:
Table "tbl_objectshelf"
Attribute | Type | Modifier
-----------+---------+----------
id | integer | not null
object | oid |
Index: tbl_objectshelf_pkey

when I run the example several times 50, 100, etc the exception is
thows:

FATAL 1: my bits moved right off the end of the world!
Recreate index pg_attribute_relid_attnum_index.
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.

>
> * I've read in some Java Usenet groups that class
> files are not as Write-Once-Read-Everywhere as Sun would like us
> to believe.
>
> This is true to a point. It depends on how pure the javac implementation is,
> and how pure the java source is. I've tried to keep the JDBC source as pure
> as possible, although I can only test it out under Linux & Windows, but it
> should be fine with Solaris. It would be interesting to see if there are any
> differences between postgresql.jar compiled under Linux & Solaris.
>
> * FATAL 1: my bits moved right off the end of the world!
> Recreate index pg_attribute_relid_attnam_index.
>
> This is internal to postgresql. It's one of my favourite error messages,
> although I've never had it myself, so I've not had to fix it before.
>
> * InputStream is = rs.getBinaryInputStream(1);
> * // use the stream in some way here
> * is.close();
>
> This should work, as it reads the entire LargeObject into a
> ByteArrayInputStream(), which is what's actually returned. However, the next
> release should return a LargeObjectInputStream object, which reads from the
> backend as and when required. This should be done by the weekend.
>
> Peter
>
> --
> Peter Mount
> Enterprise Support Officer, Maidstone Borough Council
> Email: petermount(at)maidstone(dot)gov(dot)uk
> WWW: http://www.maidstone.gov.uk
> All views expressed within this email are not the views of Maidstone Borough
> Council
>
> -----Original Message-----
> From: David Huttleston Jr [mailto:dhjr(at)hddesign(dot)com]
> Sent: Monday, October 16, 2000 9:20 PM
> To: Gabriel Lopez
> Cc: pgsql-interfaces(at)postgresql(dot)org
> Subject: Re: [INTERFACES] wrong documentation and others .....
>
> Peter Mount's JDBC driver translates the query results from the postgresql
> process to Java via the JDBC standard. As I see it, the source of your
> problem
> can be at several levels.
>
> 1) A bug in the program
> 2) A bug in the Solaris JVM
> 3) A problem with the JDBC driver
> 4) A problem with your postgresql config on the solaris
>
> #1 seems unlikely since your program and mine work on linux but not on
> solaris
> #2 seems unlikely since Solaris is the flagship for Sun's Java efforts
> #3 is possible, but our programs _and_ JDBC work fine under linux
> #4 is the only possibility we have not discussed.
>
> The first way to test if the solaris configuration of postgresql is the
> problem
> is to test a query using an interface which is _not_ JDBC. The simpliest,
> is
> psql. Test the large-object support using lo_import and lo_export from
> within
> psql. In the documentation, section IV (Interfaces)-- chapter 51 (Large
> Objects)
> has a page called 'Built in registered functions'. This page shows an
> example of how
> to 'manually' store and retrieve a large-object which can be typed into the
> psql
> interface and tested.
> If lo_import and lo_export work, but JDBC does _not_ work. We should get
> Peter
> Mount's direct attention. I don't know if he's familiar with solaris, but
> might be
> able to point you toward a solution based on your stack trace.
> Buena Suerte,
> Dave
>
> On Mon, 16 Oct 2000 18:42:17 +0200, you wrote:
> > David Huttleston Jr escribió:
> >
> > > Hey Gabi,
> > > Have you manually tested this query in using the pqsl interface?
> Perhaps
> > > it is the backend having problems and not JDBC.
> > >
> > > Dave
> > >
> >
> > What do you want to say?
> > I run your program. The problem in the postgresql?
> >
> >
> >
> > --
> > Gabriel López Millán
> > Facultad de Informática -Universidad de Murcia
> > 30001 Murcia - España (Spain)
> > Telf: +34-968-364644 E-mail: gabilm(at)dif(dot)um(dot)es
> >
> >
> >

--
Gabriel López Millán
Facultad de Informática -Universidad de Murcia
30001 Murcia - España (Spain)
Telf: +34-968-364644 E-mail: gabilm(at)dif(dot)um(dot)es