[BUGS] strange bug with vacuum
Operating system: Linux (PLD), kernel 2.2.20 Hardware: $ cat /proc/cpuinfo | grep -E "^(vendor_id|model name|cpu MHz)" vendor_id : GenuineIntel model name : Pentium III (Coppermine) cpu MHz : 871.474 $ free total used free sharedbufferscached Mem:387712 385028 2684 79864 146396179892 -/+ buffers/cache: 58740 328972 Swap: 524624 0 524624 PostgreSQL version: PostgreSQL 7.2b4 on i686-pc-linux-gnu, compiled by GCC 2.95.4 it appears that doing vacuum analyze just after creation of tables and indices permanently damages indices. our code made something like: create table(); create index .. vacuum analyze; now apporximatelly ca 10 inserts, each prepended by select id from table where field = value; field is of type int8 (value also, and we do casting to int8) and there is unique index on table.field; every 5000 inserts we do vacuum analyze of this table. the problem is that the time system spends on mentioned selects raises linear way instead of (expected) logarythmical. we checked twice that *not* making initial vacuum (while still doing vacuum analyze every 5000 inserts) does modify this behaviour to much more reasonable. is this something we are missing or another bug in postgresql? the selects and inserts are made through plpgsql function (single call select function(args) does select and insert), but i doubt if this matters. depesz -- hubert depesz lubaczewski http://www.depesz.pl/ ... vows are spoken to be broken ... [enjoy the silence] ... words are meaningless and forgettable ... [depeche mode] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] Bug #570: \d in psql does not show triggers
Gerald Vogt ([EMAIL PROTECTED]) reports a bug with a severity of 3 The lower the number the more severe it is. Short Description \d in psql does not show triggers Long Description When using \d in psql to find details of a table, occasionally triggers will not be listed although the table does have triggers. This happens when the table does not have any rules. e.g.: SELECT relhasindex, relkind, relchecks, reltriggers, relhasrules from pg_class where relname='pub_liste'; relhasindex | relkind | relchecks | reltriggers | relhasrules -+-+---+-+- t | r | 0 | 25 | f (1 row) However: \d pub_liste Table "pub_liste" Attribute | Type | Modifier ---+---+-- ... Index: pub_liste_pkey This is due to a bug in bin/psql/describe.c line 793 < if (!error && tableinfo.hasrules) should probably be > if (!error && tableinfo.triggers) Gerald Sample Code No file was uploaded with this report ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Bug #570: \d in psql does not show triggers
[EMAIL PROTECTED] writes: > This is due to a bug in bin/psql/describe.c line 793 > < if (!error && tableinfo.hasrules) > should probably be > > if (!error && tableinfo.triggers) Looks like this is already fixed in 7.2 sources. But thanks for the report! regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] strange bug with vacuum
On Fri, 1 Feb 2002, hubert depesz lubaczewski wrote: > Operating system: > Linux (PLD), kernel 2.2.20 > > Hardware: > $ cat /proc/cpuinfo | grep -E "^(vendor_id|model name|cpu MHz)" > vendor_id : GenuineIntel > model name : Pentium III (Coppermine) > cpu MHz : 871.474 > > $ free > total used free sharedbufferscached > Mem:387712 385028 2684 79864 146396179892 > -/+ buffers/cache: 58740 328972 > Swap: 524624 0 524624 > > PostgreSQL version: > PostgreSQL 7.2b4 on i686-pc-linux-gnu, compiled by GCC 2.95.4 > > > it appears that doing vacuum analyze just after creation of tables and > indices permanently damages indices. > our code made something like: > create table(); > create index .. > vacuum analyze; > now apporximatelly ca 10 inserts, each prepended by > select id from table where field = value; > field is of type int8 (value also, and we do casting to int8) and there > is unique index on table.field; > every 5000 inserts we do vacuum analyze of this table. > the problem is that the time system spends on mentioned selects raises > linear way instead of (expected) logarythmical. > > we checked twice that *not* making initial vacuum (while still doing > vacuum analyze every 5000 inserts) does modify this behaviour to much > more reasonable. > > is this something we are missing or another bug in postgresql? > > the selects and inserts are made through plpgsql function (single call > select function(args) does select and insert), but i doubt if this > matters. Well the initial vacuum analyze is going to set up sequence scan as the best plan. And yep, it does matter that it's in a function :) The query plan is going to be saved unless you use execute which means it saves the plan from the empty analyze (ie seq scan wins) at least until you start a new session. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] New to Postgresql - Backend timeout /JDBC
This is definitely not a problem with the server Tom Lane has told me and I have verified the with my sources. It seems to be in the JDBC driver. It only seems to happen when the JDBC client and the postgresql server are on seperate machines and possibly on different networks. I have further talked with the site where it happens and researched the isClosed() JDBC call. The isClosed() call according to my sources is only required to tell you if you have closed the connection not if the connection has been closed by a timeout. The isClosed() call in Oracle is non-functional about timeouts across a wan. I should have read the JDBC spec and not just the documentation. I will not make that same mistake again when it comes to JDBC. I have verified that the connections stay active when the JDBC client and the postgresql server are on the same machine. If your connections are across a LAN and not the same machine then that would be helpful as I will only have to research a problem with a wan and that might not be a problem at all for my configuration. I will start my research with two machines on the same LAN unless you can tell me that your configuration is across a LAN. TIA for any info. At 11:49 AM 2/1/2002 +0100, Stefano Reksten wrote: >At 12.57 31/01/02 -0500, you wrote: >>However, I'm not very familiar with Java and so I cannot dismiss the >>possibility that some layer inside the JVM might take it upon itself >>to close an open TCP connection after a period of inactivity. > >I have a Connection Pool active 365/24/7 on a site I manage, and the >connections are opened, reused, but not closed, and I never had such a >problem; HTH. > >>The pgsql-jdbc list might be a better place to ask if anyone knows of >>such problems in a JDBC context. Not sure how many JDBC people read >>pgsql-bugs. > >Well, at least one ;) > >Ciao, > Stefano > > >---(end of broadcast)--- >TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] postgresql-7.2b3+jdbc+DatabaseMetaData
I test postgresql-7.2rc2 with the following configuration: AMD1.3Ghz on ASUS A7, 512MB RAM, 3Ware Raid0 SuSE 7.3, 2.4.10-4GB, gcc 2.95.3 postgresql.jar is unusable with suns forte4j v3. most calls from the database explorer to the DatabaseMetaData fails with exceptions. postgresql.jar ( vers 7.1.3 ) is far from beeing complete, but works without errors. are you aware of this problems ? thanks raimund jakobsmeyer [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[BUGS] Bug to restore OID with pg_restore
Hi, My server is a postgres v7.1.3. I have a database with OID and to backup my database i use this syntaxe : pg_dump -Ft -b -o -f mydb.tar mydb when i want restore my database i use this command line: pg_restore -o -d mydb mydb.tar and i have this error : Archiver(db): Could not execute query. No result from backend. Could you help me, because i can't put my database offline and so i can't restore it with pg_restore. I hope i am clear about my problem. Hoping to hear from you soon. Annie. Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] plpgsql support
hello sir, I have written a function. The language used is sql. I am not getting error if I assign an alias to a variable or if I try to declare any of the variable. I could figure out that I require support if plpgsql, but I am not able to get the suppor of this language. I have tried CREATE PROCEDURAL LANGUAGE 'plpgsql' HANDLER plpgsql_call_handler LANCOMPILER 'PL/PGSQL' I have even tried CREATE LANGUAGE 'plpgsql' But I am not able to set it. What is that I should do to set up this language support. Regards nagesh
[BUGS] psql in 7.2devel loops
It used to be the case that psql could be run thus: psql -U summer -h numbat template1 < ZZ which is very convenient in scripting. Now, it writes a password prompt (successfully in my case) and tries to read the password (presumably from the tty) which fails. Here is the entire script that fails for me: #!/bin/bash set -x psql -U summer -h $HOSTNAME template1 <&1) \ | /usr/sbin/sendmail -t & ) Presumably opening the tty worked - there is stil a terminal associated with the script. The environment is Red Hat Linux 7.2, 2.4.17 kernel. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] optimizer fails to find indexes
This is a two-part bug report. The first part is something that I feel is an obscure bug, the other would be considered 'optimizer acrobatics' I have 3 tables: TABLEA, TABLEB, TABLEC TABLEA has integer columns XID and AID, with a unique index on (XID,AID) and a regular index on AID TABLEB has integer columns XID and BID, with a unique index on (XID,BID) and a regular index on BID TABLEC has integer columns XID and CID, with a unique index on (XID,CID) and a regular index on CID. All three tables have populations in excess of 100,000 rows. I created a view: create table_view as select XID, AID as YID, 'A' as TABLE_TYPE from TABLEA UNION ALL select XID, BID as YID, 'B' as TABLE_TYPE from TABLEB UNION ALL select XID, CID as YID, 'C' as TABLE_TYPE from TABLEC; When I do the following query EXPLAIN select * from table_view where YID = 17 and TABLE_TYPE = 'A'; I get the following query plan (this is actual output, I changed the names in the example above): Subquery Scan test_view (cost=0.00..39088.27 rows=2029327 width=20) -> Append (cost=0.00..39088.27 rows=2029327 width=20) -> Subquery Scan *SELECT* 1 (cost=0.00..16857.65 rows=871365 width=20) -> Seq Scan on enrollstudentschool (cost=0.00..16857.65 rows=871365 width=20) -> Subquery Scan *SELECT* 2 (cost=0.00..4976.23 rows=286723 width=8) -> Seq Scan on enrollstudentclassgroup (cost=0.00..4976.23 rows=286723 width=8) -> Subquery Scan *SELECT* 3 (cost=0.00..17254.39 rows=871239 width=20) -> Seq Scan on enrollstudentdistrict (cost=0.00..17254.39 rows=871239 width=20) So, here's the first problem: In all three cases, the optimizer should have seen that there was an index on AID/BID/CID respectively, and used that. Instead, it table scanned all three large tables. I suspect this may be because the optimizer doesn't translate the column name from view name to table name before looking for a suitable index. The second part is more feature request than bug report: the optimizer could have noticed that the TABLE_TYPE value of 'A' never occurs with the other two tables, and could have avoided querying them entirely. This feature exists in Oracle, and I've used it to great effect there. Thanks for your time. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] Queries Errors
Hi, I've installed Postgres 7.0.3. The bug I founded was very weird. I've this query that I run in my app. For example, give a list of all sales from all my stores around the country. The query runs very fast and I get the result I want. Later, I try to reduce the search and instead of list all stores, I want to list only one store. The query runs but this time is slower than before (I have the proper indexes in that table). In this case, we're using the same query but with one more condition. I looked at the query with the explain command and I saw that Postgres wasn't using the sentence where I ask only for one store. Accidentally, I made a mistake and wrote the one store sentence twice in that query. My surprise was that the query did work!!!. When the query had the same sentence written twice it actually worked fine and it took fewer time than before. None has known how to repair this. In some queries, duplicating some senteces makes it work. In other queries, it doesn't. Please, if you know how to correct this let me know. Carlos E.AtencioCaracas-Venezuela
[BUGS] initdb problems
I am trying to use postgres with the CYGWIN binaries for WIN/2000. I started initdb with '--debug' and it got as far as postgres -boot -x! -C -F -DDatabase -d template1 and then just sat there with 'postgres' consuming CPU, but not appearing to do anything. Has something similar been reported before.
[BUGS] PostgresSQL 7.1.3 not parsing SELECT portion of SQL correctly
POSTGRESQL BUG REPORT TEMPLATE
Your name : Mark Jeacocke
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : AMD Athlon XP 1600
Operating System (example: Linux 2.0.26 ELF) : RedHat Linux 7.0 Kernel
2.4.2
PostgreSQL version (example: PostgreSQL-7.1.3): PostgreSQL-7.1.3
Compiler used (example: gcc 2.95.2) : Downloaded offical RPMS from
Postgres mirror
Please enter a FULL description of your problem:
Seems to be a parsing problem in the select portion of the SQL statement:
select DISTINCT TABLEID, '' AS ALIAS from TABLE; :FAILS
select DISTINCT TABLEID, 'test' AS ALIAS from TABLE; :FAILS
select DISTINCT TABLEID, Null AS ALIAS from TABLE; :FAILS
select DISTINCT TABLEID, trim('') AS ALIAS from TABLE; :SUCCEEDS
select DISTINCT TABLEID, 2 AS ALIAS from TABLE; :SUCCEEDS
I believe all five queries should succeed.
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
See above.
If you know how this problem might be fixed, list the solution below:
-
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] array_dims function is poorly behaved
Simply use an array_dims() on any non-array type, the messages vary from: SIS=# select array_dims(datdba) from pg_database; 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: Failed. !# ; You are currently not connected to a database. !# \q to: SIS=# select array_dims(datname) from pg_database; ERROR: MemoryContextAlloc: invalid request size 1702125936 Reproduces consistently on Linux (i386) 2.4.16 running 7.1.3. Cheers, Marc L. -- 01010101010101010101010101010101010101010101010101 Marc P. Lavergne [wk:407-648-6996] Product Development richLAVA Corporation -- "Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network." -Tim Berners-Lee (Technology Review, July 1996) 01010101010101010101010101010101010101010101010101 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] plpgsql support
On Tue, 29 Jan 2002, Nagasubramanya L wrote: > I have even tried > CREATE LANGUAGE 'plpgsql' > > But I am not able to set it. What is that I should do to set up this language >support. Use the shell script createlang createlang plpgsql should add it to the database in question. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[BUGS] cant activate the database ?
hello, i have downloaded all the packages through cygwin setup and installed it (including supplied postgresql) and when i run the command: /usr/bin/postmaster -i -D /database it outputs: $ 0 [main] postmaster 404 fixup_mmaps_after_fork: base address fails to match requested address 0x3B E:\installed\psql\bin\postgres.exe: *** recreate_mmaps_after_fork_failed /usr/bin/postmaster: Startup proc 404 exited with status 256 - abort [4]- Exit 1 /usr/bin/postmaster -i -D /database and if i try the command: /usr/bin/pg_ctl -D /database -l logfile start it start perfectly but i havent been able to access it through JDBC since i didnt activate the -i option (which is not available through this command), so i am asking can you answer whats wrong with it? or can you direct me to the right place? thanks ahead, Respectfully, __ Shay Bar-Califa, R&D Manager, 2Shade Israel. Address: Pinhassi St. 2/6 Petach-Tikva 49503, Israel. E-Mail: [EMAIL PROTECTED] Site: http://www.2shade.com Phone: 972-3-528 41 75 Mobal: 972-52-818 525 --- Proprietary and Confidential Information. The information transmitted is intended only for the person(s) or entity(ies) to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. --- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Bug to restore OID with pg_restore
=?utf-8?Q?[EMAIL PROTECTED]?= wrote: > Hi, > > My server is a postgres v7.1.3. > I have a database with OID and to backup my database i use this syntaxe : > pg_dump -Ft -b -o -f mydb.tar mydb > when i want restore my database i use this command line: > pg_restore -o -d mydb mydb.tar > and i have this error : > Archiver(db): Could not execute query. No result from backend. > > Could you help me, because i can't put my database offline and so i can't restore it >with pg_restore. > > I hope i am clear about my problem. > Hoping to hear from you soon. We only discovered this but recently, about two weeks ago. We have a fix in PostgreSQL 7.2RC2. I think you can compile 7.2 and use that pg_restore on a 7.1 database to restore. It is the combination of -Ft and -o that was at fault. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] initdb problems
All CYGWIN users, make sure that cygipc is on your machine and running before doing anything with Postgres. Michaele Holtman wrote: [EMAIL PROTECTED]"> I am trying to use postgres with the CYGWIN binaries for WIN/2000. I started initdb with '--debug' and it got as far as postgres -boot -x! -C -F -DDatabase -d template1 and then just sat there with 'postgres' consuming CPU, but not appearing to do anything. Has something similar been reported before.
Re: [BUGS] psql in 7.2devel loops
John Summerfield <[EMAIL PROTECTED]> writes: > It used to be the case that psql could [ read a password from stdin ] > Now, it writes a password prompt (successfully in my case) and tries to > read the password (presumably from the tty) which fails. This was a deliberate change. I wasn't that happy with it myself, but I was outvoted. You're gonna have to find another way; sorry. I think "expect" was mentioned as one way of feeding passwords to programs that will only talk to a tty. On the whole, though, you'd be better off not embedding passwords in scripts in the first place. Consider rethinking your PG authorization strategy. (On Linux, at least, "ident" now works nicely across Unix sockets.) regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Queries Errors
"Carlos Atencio" <[EMAIL PROTECTED]> writes: > I've installed Postgres 7.0.3. Consider upgrading to something current (7.1.3, or better 7.2 which should be out Monday). > None has known how to repair this. In some queries, duplicating some se= > nteces makes it work. In other queries, it doesn't. You're not likely to get useful help without showing us the exact queries, explain results, and underlying table schemas. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] initdb problems
"Michaele Holtman" <[EMAIL PROTECTED]> writes: > I am trying to use postgres with the CYGWIN binaries for WIN/2000. I start= > ed initdb with '--debug' and it got as far as > postgres -boot -x! -C -F -DDatabase -d template1 > and then just sat there with 'postgres' consuming CPU, but not appearing to= > do anything. This is reportedly what happens if you haven't installed/started "cygipc" first. Please see our installation instructions for Windows. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Sun Solaris 2.5.1 Seg Faults PostgreSQL7.1.3 build com mands
"Riendeau, Mike" <[EMAIL PROTECTED]> writes: > rpath is the same (at least in all Makes in the source root) > Both config runs have the same parameters. So, something other > than the setting of rpath is going on here. Have you set LD_LIBRARY_PATH to point to whereever libreadline lives? Holger never got back to us with a fix either; without access to a Solaris machine there's not much I can do about it. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Sun Solaris 2.5.1 Seg Faults PostgreSQL7.1.3 build com
Your name : Mike Riendeau Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) : Sun Sparc 20 Operating System (example: Linux 2.0.26 ELF) : Solaris 2.5.1 PostgreSQL version (example: PostgreSQL-7.1.3): PostgreSQL-7.1.3 Compiler used (example: gcc 2.95.2) : gcc 2.95.2 Please enter a FULL description of your problem: I am having a problem with v7.1.3 PostgreSQL commands generating Seg. Faults on exit. (Continued) Steps taken on this pass: 1) built readline4.2a successfully. 2) Ran PGv7.1.3 configure as follows with a clean cache. ./configure --prefix=/home/mriendea --with-tcl --with-tclconfig=/home/mriendea/lib --with-tkconfig=/home/mriendea/lib --with-includes=/home/mriendea/include --with-pgport=8000 --with-odbc --enable-debug --with-libs=/home/mriendea/lib --enable-debug Without 'gmake install' of the new readline lib, the script sees the same readline used to build PGv7.0.2 and completes successfully. Of course the Seg Fault behavior is apparent. 3) 'gmake install' of the new readline lib. 4) Ran PGv7.1.3 configure with a clean cache again. The script now sees the new readline4.2a lib and crashes with the identical problem reported by Holger Mittewald bug #490. (test following optreset bails the config script for some reason.) rpath is the same (at least in all Makes in the source root) Both config runs have the same parameters. So, something other than the setting of rpath is going on here. Or I do not understand how it all works (Definite possibility). Synopsys of configure with above switches: PROCESS Tested readlineConfig gmake installedrun version libs - Pgv7.0.2systemyes yes v7.0.2 yes Pgv7.1.3systemyes yes v7.0.2 v7.1.3 pgsql, createdb seem to work with new db. (brief testing) Pgv7.1.3systemyes yes v7.1.3 Seg. Faults on exit for pgsql, createdb ... Pgv7.1.3v4.2a bails n/a n/an/a after optreset Giving up soon, Mike Riendeau ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] array_dims function is poorly behaved
Marc Lavergne <[EMAIL PROTECTED]> writes: > Simply use an array_dims() on any non-array type, There is not a lot to be done about that, I'm afraid, since our type system doesn't have a concept of "any array type". The only way we have to declare array_dims() is as a function taking any type at all; so it can't protect itself against inputs that aren't arrays. We could add some code in array_dims to try to detect the case where it's handed a non-array pass-by-reference type; but I don't see how it can guard against a pass-by-value parameter, which will typically equate to an invalid pointer :-( A bulletproof solution would require adding the notion of "any array type" to the type checking system. That might be a good thing to do someday, but I'm not planning to hold my breath while waiting... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] PostgresSQL 7.1.3 not parsing SELECT portion of SQL correctly
"Mark Jeacocke" <[EMAIL PROTECTED]> writes: > select DISTINCT TABLEID, '' AS ALIAS from TABLE; :FAILS We get this type of complaint regularly. Perhaps DISTINCT should resolve unknown-type inputs to "text", much as we do with CASE and UNION constructs when we see an untyped literal. Thoughts? regards, tom lane PS: in the meantime, Mark, try casting the literal to text. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] JDBC- SQLException results returned?
i am seeing postgre 6.4 return the following error message when performing a JDBC update with executeUpdate(). any ideas what it means? ava.sql.SQLException: results returned at java.lang.Throwable.(Compiled Code) at java.lang.Exception.(Compiled Code) at java.sql.SQLException.(Compiled Code) at postgresql.Statement.executeUpdate(Compiled Code) at postgresql.PreparedStatement.executeUpdate(Compiled Code) at InsertError.record(Compiled Code) at InsertError.record(Compiled Code) at wbCheckUrl$CheckThread.run(Compiled Code) java.lang.ArrayIndexOutOfBoundsException: 8 at wbCheckUrl.checkUrl(Compiled Code) at wbCheckUrl$CheckThread.run(Compiled Code) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
