Thread: wrong documentation and others .....
<p> Hi all. <p> I have several days working with LargeObject and postgres 7.0.2 and I have found many
problems.In the first time the postgresql doc is wrong, in chapter 58 of PosgreSQL tutorial (JDBC Interfaces) it repot
whoto work with Large Object and give code that is wrong: <p> File file = new File("myimage.gif"); <br />
FileInputStreamfis = new FileInputStream(file); <br /> PreparedStatement ps = conn.prepareStatement("insert into
imagesvalues (?,?)"); <br /> ps.setString(1,file.getName()); <br />
ps.setBinaryStream(2,fis,file.length());<br /> ps.executeUpdate(); <br /> ps.close(); <br />
fis.close();<p> PreparedStatement ps = con.prepareStatement("select oid from images where name=?"); <br
/> ps.setString(1,"myimage.gif"); <br /> ResultSet rs = ps.executeQuery(); <br /> if(rs!=null) {
<br/> while(rs.next()) { <br /> InputStream is = rs.getBinaryInputStream(1); <br
/> // use the stream in some way here <br /> is.close(); <br /> } <br
/> rs.close(); <br /> } <br /> ps.close(); <br /> <p> InputStream ARE NOT SUPPORTED in
JDBCimplementation ¡¿?¡ and "getBinaryInputStream()" really is "getBinaryStream()". I think that it is very serious.
Theother method (that I know) is using LargeObjectAPI, but this fail every 9 times of PreparedStatement of setObject()
sentence¡¡¡ and when use LargeObjectManager as in source examples. (I send other messages to list) <br /> <p>
HasPostgreSQL any way to work WELL with LargeObject.? <p> Please reply me. <p> Cheers, Gabi. <br /> <pre>--
Gabriel López Millán
Facultad de Informática -Universidad de Murcia
30001 Murcia - España (Spain)
Telf: +34-968-364644 E-mail: gabilm@dif.um.es</pre>
Hi try this:
File file = new File("myimage.gif");
FileInputStream fis = new FileInputStream(file);
FileInputStream fis = new FileInputStream(file);
byte[] theByteArray = new byte[fis.available()];
fis.read(theByteArray);
PreparedStatement ps = con.prepareStatement("insert insert into images values (?,?)");
ps.setString(1,file.getName());
ps.setBytes(2, theByteArray);
ps.execute();
con.commit();
ps.close();
fis.close();
ps.setBytes(2, theByteArray);
ps.execute();
con.commit();
ps.close();
fis.close();
TJM
----- Original Message -----From: Gabriel LopezTo: psqlSent: Thursday, October 05, 2000 12:59 PMSubject: [INTERFACES] wrong documentation and others .....Hi all.
I have several days working with LargeObject and postgres 7.0.2 and I have found many problems. In the first time the postgresql doc is wrong, in chapter 58 of PosgreSQL tutorial (JDBC Interfaces) it repot who to work with Large Object and give code that is wrong:
File file = new File("myimage.gif");
FileInputStream fis = new FileInputStream(file);
PreparedStatement ps = conn.prepareStatement("insert into images values (?,?)");
ps.setString(1,file.getName());
ps.setBinaryStream(2,fis,file.length());
ps.executeUpdate();
ps.close();
fis.close();PreparedStatement ps = con.prepareStatement("select oid from images where name=?");
ps.setString(1,"myimage.gif");
ResultSet rs = ps.executeQuery();
if(rs!=null) {
while(rs.next()) {
InputStream is = rs.getBinaryInputStream(1);
// use the stream in some way here
is.close();
}
rs.close();
}
ps.close();
InputStream ARE NOT SUPPORTED in JDBC implementation ¡¿?¡ and "getBinaryInputStream()" really is "getBinaryStream()". I think that it is very serious. The other method (that I know) is using LargeObjectAPI, but this fail every 9 times of PreparedStatement of setObject() sentence ¡¡¡ and when use LargeObjectManager as in source examples. (I send other messages to list)
Has PostgreSQL any way to work WELL with LargeObject.?
Please reply me.
Cheers, Gabi.
-- Gabriel López Millán Facultad de Informática -Universidad de Murcia 30001 Murcia - España (Spain) Telf: +34-968-364644 E-mail: gabilm@dif.um.es
Troels Jegbjaerg Moerch escribió:
> Hi try this: File file = new File("myimage.gif");
> FileInputStream fis = new FileInputStream(file);
> byte[] theByteArray = new byte[fis.available()];
> fis.read(theByteArray);
>
> PreparedStatement ps = con.prepareStatement("insert insert into
> images values (?,?)"); ps.setString(1,file.getName());
> ps.setBytes(2, theByteArray);
> ps.execute();
> con.commit();
> ps.close();
> fis.close();
> TJM
Yes, it work fine, but each 9 times it fail:
FATAL 1: my bits moved right off the end of the world! Recreate index pg_attribute_relid_attnam_index.
Anybody known why?
Thanks
--
Gabriel López Millán
Facultad de Informática -Universidad de Murcia
30001 Murcia - España (Spain)
Telf: +34-968-364644 E-mail: gabilm@dif.um.es
Has anybody try this?
I don't know why this error appear.
Please, reply me.
Thanks, Gabi.
Gabriel Lopez escribió:
> Troels Jegbjaerg Moerch escribió:
>
> > Hi try this: File file = new File("myimage.gif");
> > FileInputStream fis = new FileInputStream(file);
> > byte[] theByteArray = new byte[fis.available()];
> > fis.read(theByteArray);
> >
> > PreparedStatement ps = con.prepareStatement("insert insert into
> > images values (?,?)"); ps.setString(1,file.getName());
> > ps.setBytes(2, theByteArray);
> > ps.execute();
> > con.commit();
> > ps.close();
> > fis.close();
> > TJM
>
> Yes, it work fine, but each 9 times it fail:
>
> FATAL 1: my bits moved right off the end of the world!
> Recreate index pg_attribute_relid_attnam_index.
>
> Anybody known why?
>
> Thanks
>
> --
> Gabriel López Millán
> Facultad de Informática -Universidad de Murcia
> 30001 Murcia - España (Spain)
> Telf: +34-968-364644 E-mail: gabilm@dif.um.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@dif.um.es
Hi Gabriel,
We have been using the postgresql JDBC to serialize classes and have
had no problems since we figured out that the doc's are wrong. I had
to find answers in the source code.
I've attached a class called Shelf which serializes any java object to a
table. Within the code is the schema of a table called tbl_objectshelf which
is suitable as a "shelf". I hope this saves you some time.
Have fun,
Dave
On Thu, 05 Oct 2000 12:59:53 +0200, you wrote:
>
>
> Hi all.
>
> I have several days working with LargeObject and postgres 7.0.2 and
> I have found many problems. In the first time the postgresql doc is
> wrong, in chapter 58 of PosgreSQL tutorial (JDBC Interfaces) it repot
> who to work with Large Object and give code that is wrong:
>
> File file = new File("myimage.gif");
> FileInputStream fis = new FileInputStream(file);
> PreparedStatement ps = conn.prepareStatement("insert into images
> values (?,?)");
> ps.setString(1,file.getName());
> ps.setBinaryStream(2,fis,file.length());
> ps.executeUpdate();
> ps.close();
> fis.close();
>
> PreparedStatement ps = con.prepareStatement("select oid from
> images where name=?");
> ps.setString(1,"myimage.gif");
> ResultSet rs = ps.executeQuery();
> if(rs!=null) {
> while(rs.next()) {
> InputStream is = rs.getBinaryInputStream(1);
> // use the stream in some way here
> is.close();
> }
> rs.close();
> }
> ps.close();
>
>
> InputStream ARE NOT SUPPORTED in JDBC implementation ��?� and
> "getBinaryInputStream()" really is "getBinaryStream()". I think that it
> is very serious. The other method (that I know) is using LargeObjectAPI,
> but this fail every 9 times of PreparedStatement of setObject() sentence
> ��� and when use LargeObjectManager as in source examples. (I send other
> messages to list)
>
>
> Has PostgreSQL any way to work WELL with LargeObject.?
>
> Please reply me.
>
> Cheers, Gabi.
>
>
> --
> Gabriel L�pez Mill�n
> Facultad de Inform�tica -Universidad de Murcia
> 30001 Murcia - Espa�a (Spain)
> Telf: +34-968-364644 E-mail: gabilm@dif.um.es
>
>
>
>
Attachment
David Huttleston Jr escribió: <blockquote type="CITE">Hi Gabriel, <br /> We have been using the postgresql JDBC toserialize classes and have <br />had no problems since we figured out that the doc's are wrong. I had <br />to find answersin the source code. <br /> I've attached a class called Shelf which serializes any java object to a <br />table. Within the code is the schema of a table called tbl_objectshelf which <br />is suitable as a "shelf". I hope thissaves you some time. <p> Have fun, <br /> Dave <br /> </blockquote><p><br /> Yes, your codework fine, as my code, in Linux. I don't know if in any of my older messages say that I'm working with solaris, if no,sorry: <br /> SunOS maquina 5.7 Generic_106541-02 sun4u sparc SUNW,Ultra-5_10 <p> Yourcode also fail in solaris when your run the program several times. <pre>-- Gabriel López Millán Facultad de Informática -Universidad de Murcia 30001 Murcia - España (Spain) Telf: +34-968-364644 E-mail: gabilm@dif.um.es</pre>
Hola Gabi,I have an idea. 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. If you are using one of the Jar files provided by Peter Mount
it might be a good idea to compile the JDBC class from source.Compiling on your systems could help in two ways. The
compiler
could spot the problem e.g. a name collison. Also, the solaris javac might
produce class files which do not cause the error in your solaris JVM.Another thought, is there any chance you have an
oldversion of
the postgresql JDBC drivers in the classpath of your solaris system?
I had an annoying bug once myself when an old version of a library
was in my classpath before the proper version, so the old-buggy
version was the library being used.
Hasta Luego,Dave
On Wed, 11 Oct 2000 09:52:28 +0200, you wrote:
> David Huttleston Jr escribi�:
>
> > Hola Gaberiel,
> > I have a some questions to try to help track down your problem.
> >
>
> Hola David. Thanks to reponse. I will try to related my problem in detail.
>
> >
> > 1) Which program of mine did you run? Was is the shelf I sent first, or the
> > better cleaned up version I posted as 'An Example of Large Objects and JDBC'?
>
> The second. The only change is to add a "for" sentence.
>
> for (int i = 0; i < 50; i++) {
> // build an sample object to save on the shelf
> ArrayList stuff = new ArrayList();
> ........
> Integer key = new Integer(i);
> ...........
> }
>
> Even the original code, when is running serveral times also fail.
>
> > 2) What version of the postgresql JDBC driver are you using?
>
> I'm using postgresql-7.0.2 with the original jdbc drivers in the
> distribution. This have installed the jdbc6.3.tar.gz patch. I'm not installed ANY patch
> or others drivers.
>
> >
> > 3) What version of JVM 1.2?
>
> As I say in the previous message in Linux the code work fine, but it fail
> in Solaris. I'm using
> SunOS myhost 5.7 Generic_106541-02 sun4u sparc SUNW,Ultra-5_10
> And yes, I'm using jvm1.2
>
> >
> > 4) Are you using a JIT?
>
> NO
>
> >
> > 5) How are you running the program? (Stand-alone, as a Servlet, ...)
>
> Your code in running stand-alone.
>
> > 6) When the program fails, can you print a stacktrace?
>
> Whit the above interation:
>
> bash-2.03# java TestShelf
> The second item within stuff: my 2nd thing
> The second item within stuff: my 2nd thing
> The second item within stuff: my 2nd thing
> FATAL 1: my bits moved right off the end of the world!
> Recreate index pg_attribute_relid_attnam_index.
> FastPath call returned FATAL 1: my bits moved right off the end of the world!
> Recreate index pg_attribute_relid_attnam_index.
>
> at org.postgresql.fastpath.Fastpath.fastpath(Compiled Code)
> at org.postgresql.fastpath.Fastpath.fastpath(Compiled Code)
> at org.postgresql.fastpath.Fastpath.getInteger(Compiled Code)
> at org.postgresql.largeobject.LargeObjectManager.create(Compiled Code)
> at org.postgresql.jdbc2.PreparedStatement.setBytes(Compiled Code)
> at Shelf.putObject(Compiled Code)
> at TestShelf.main(Compiled Code)
>
> >
> >
> > Problems that happen after a few executions, in-my-experience, usually happen
> > when resources (like connections) are not being released correctly. Hopefully
> > we can track down why if we know your enviroment better.
> >
>
> I think that is not a problem of code. It seem that is a problem with solaris
>
> >
> > Adios,
> > David
> >
>
> Thanks for your time, Gabi.
>
> --
> Gabriel L�pez Mill�n
> Facultad de Inform�tica -Universidad de Murcia
> 30001 Murcia - Espa�a (Spain)
> Telf: +34-968-364644 E-mail: gabilm@dif.um.es
>
>
>
Hola. I will try this. It can be a solution. If this work I will notify to the list. Thanks for your time, Gabi. David Huttleston Jr escribió: > Hola Gabi, > I have an idea. 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. If you are using one of the Jar files provided by Peter Mount > it might be a good idea to compile the JDBC class from source. > Compiling on your systems could help in two ways. The compiler > could spot the problem e.g. a name collison. Also, the solaris javac might > produce class files which do not cause the error in your solaris JVM. > Another thought, is there any chance you have an old version of > the postgresql JDBC drivers in the classpath of your solaris system? > I had an annoying bug once myself when an old version of a library > was in my classpath before the proper version, so the old-buggy > version was the library being used. > Hasta Luego, > Dave > -- Gabriel López Millán Facultad de Informática -Universidad de Murcia 30001 Murcia - España (Spain) Telf: +34-968-364644 E-mail: gabilm@dif.um.es
Hi again. Sorry to be late. I have recompiled the jdbc drivers in Solaris and it fail again. I have see the
source code and I only can arrive to see the error in:
org/postgresql/fastpath/FasPath.java
in the method:
public Object fastpath(int fnid,boolean resulttype,FastpathArg[] args)
the fail is in the loop reading the result: sometime a 'E' element is return after a 'Z'
Cheers, Gabi.
Gabriel Lopez escribió:
> Hola.
>
> I will try this. It can be a solution. If this work I will notify to the list.
>
> Thanks for your time, Gabi.
>
> David Huttleston Jr escribió:
>
> > Hola Gabi,
> > I have an idea. 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. If you are using one of the Jar files provided by Peter Mount
> > it might be a good idea to compile the JDBC class from source.
> > Compiling on your systems could help in two ways. The compiler
> > could spot the problem e.g. a name collison. Also, the solaris javac might
> > produce class files which do not cause the error in your solaris JVM.
> > Another thought, is there any chance you have an old version of
> > the postgresql JDBC drivers in the classpath of your solaris system?
> > I had an annoying bug once myself when an old version of a library
> > was in my classpath before the proper version, so the old-buggy
> > version was the library being used.
> > Hasta Luego,
> > Dave
> >
>
> --
> Gabriel López Millán
> Facultad de Informática -Universidad de Murcia
> 30001 Murcia - España (Spain)
> Telf: +34-968-364644 E-mail: gabilm@dif.um.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@dif.um.es
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@dif.um.es > > >
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. * 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@maidstone.gov.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@hddesign.com] Sent: Monday, October 16, 2000 9:20 PM To: Gabriel Lopez Cc: pgsql-interfaces@postgresql.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@dif.um.es > > >
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
probablymeans the backend terminated abnormally before or while processing the request. The
connectionto 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@maidstone.gov.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@hddesign.com]
> Sent: Monday, October 16, 2000 9:20 PM
> To: Gabriel Lopez
> Cc: pgsql-interfaces@postgresql.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@dif.um.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@dif.um.es
Gabriel Lopez <gabilm@dif.um.es> writes:
> 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'));
> 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.
We've heard a couple reports of this failure during large-object creation,
but I've never had any luck duplicating the problem :-(
regards, tom lane
Well, when can I report this error? This is very important for me
Tom Lane escribió:
> Gabriel Lopez <gabilm@dif.um.es> writes:
> > 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'));
>
> > 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.
>
> We've heard a couple reports of this failure during large-object creation,
> but I've never had any luck duplicating the problem :-(
>
> regards, tom lane
--
Gabriel López Millán
Facultad de Informática -Universidad de Murcia
30001 Murcia - España (Spain)
Telf: +34-968-364644 E-mail: gabilm@dif.um.es
Gabriel Lopez <gabilm@dif.um.es> writes:
> Well, when can I report this error? This is very important for me
When you can produce a self-contained test case that others can
replicate ;-). I've tried several times to find this problem on
the basis of bug reports that were about as detailed as the one
you just gave, and had no luck. I'm not going to spend more time
on it until I have a reproducible test case to work on.
regards, tom lane