Re: [HACKERS] [BUGS] Bug #613: Sequence values fall back to previously chec
I noticed a message asking if this scenario was consistent with the other reports, and yes it is. We have seen this occuring on our system with versions as old as 7.0. Glad to see someone has finally nailed this one. Dave ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] [BUGS] Bug #926: if old postgresql.jar in CLASSPATH,
Yes, agreed
Dave
On Sun, 2003-08-17 at 09:57, Palle Girgensohn wrote:
> It's been in use for the freebsd port for some months now, so I say
> yes. ;-)
>
> /Palle
>
> lördagen den 16 augusti 2003 kl 22.54 skrev Bruce Momjian:
>
> >
> > Is this patch valid for inclusion in jdbc?
> >
> > ---
> >
> >
> > [EMAIL PROTECTED] wrote:
> >> Palle Girgensohn ([EMAIL PROTECTED]) reports a bug with a severity
> >> of 3
> >> The lower the number the more severe it is.
> >>
> >> Short Description
> >> if old postgresql.jar in CLASSPATH, ant fails
> >>
> >> Long Description
> >> See http://www.freebsd.org/cgi/query-pr.cgi?pr=48878
> >>
> >> If there is an older postgresql.jar file in the ant classpath when
> >> building a new postgresql.jar, it will fail.
> >>
> >> Sample Code
> >> Adding includeAntRuntime="no" to the compile target in build.xml, as
> >> suggested by Tetsurou Okazaki <[EMAIL PROTECTED]>, fixes the >> problem
> >>
> >> --- src/interfaces/jdbc/build.xml~ Sun Oct 20 02:10:55 2002
> >> +++ src/interfaces/jdbc/build.xml Mon Mar 3 12:10:37 2003
> >> @@ -101,7 +101,7 @@
> >>
> >>
> >>
> >> -
> >> + >> destdir="${builddir}" debug="${debug}">
> >>
> >>
> >>
> >>
> >>
> >> No file was uploaded with this report
> >>
> >>
> >> ---(end of
> >> broadcast)---
> >> TIP 3: if posting/reading through Usenet, please send an appropriate
> >> subscribe-nomail command to [EMAIL PROTECTED] so that your
> >> message can get through to the mailing list cleanly
> >>
> >
> > --
> > Bruce Momjian | http://candle.pha.pa.us
> > [EMAIL PROTECTED] | (610) 359-1001
> > + If your life is a hard drive, | 13 Roberts Road
> > + Christ can be your backup.| Newtown Square, Pennsylvania
> > 19073
>
>
> ---(end of broadcast)---
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
>
--
Dave Cramer <[EMAIL PROTECTED]>
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [JDBC] [BUGS] Bug #886: jdbc "update row" can mess up other
Patch Applied,
Thanks,
Dave
On Mon, 2003-11-03 at 04:45, Kris Jurka wrote:
> Half of this bug was fixed at some point, but an exception is still thrown
> when calling rs.afterLast() and then rs.previous(). Attached is a
> regression test addition and the appropriate fix. Sorry for the extreme
> delay in response and thanks for the thorough report.
>
> Kris Jurka
>
> On Fri, 24 Jan 2003 [EMAIL PROTECTED] wrote:
>
> > Andrew Fyfe ([EMAIL PROTECTED]) reports a bug with a severity of 3
> > The lower the number the more severe it is.
> >
> > Short Description
> > jdbc "update row" can mess up other columns
> >
> > Long Description
> > The attached program when run gives me the following output
> >
> > DatabaseProductName: PostgreSQL
> > DatabaseProductVersion: 7.3.1
> > DriverName: PostgreSQL Native Driver
> > DriverVersion: PostgreSQL 7.3.1 JDBC3 jdbc driver build 106
> > --- Forward ---
> > 1: Colombian 7.99
> > 2: French_Roast9.99
> > --- Backward ---
> > 2: French_Roast9.99
> > 1: Colombian 7.99
> > --- Update Row 2 ---
> > --- Forward ---
> > 1: Colombian 7.99
> > 2: Colombian 10.99
> >
> > Note that the update of the price in row 2 caused jdbc to misrepesent the name.
> > If one does not run through the rows backward (give the arg "b" when running the
> > code), then the output is correct:
> >
> > --- Forward ---
> > 1: Colombian 7.99
> > 2: French_Roast9.99
> > --- Update Row 2 ---
> > --- Forward ---
> > 1: Colombian 7.99
> > 2: French_Roast10.99
> >
> > Suppressing the first forward pass through the data (giving "f" or "fb" to
> > suppress both) will cause an exception to be thrown.
> >
> > Note that another forward pass after the backward makes the problem go away.
> >
> > Sample Code
> > import java.util.*;
> > import java.sql.*;
> >
> > class pgbug
> > {
> > static String url = "jdbc:postgresql://localhost/cdb";
> > static String driver = "org.postgresql.Driver";
> > static String userName = "cdb";
> > static String password = "cdb";
> >
> > public static void print(ResultSet rs) {
> > try {
> > String s = rs.getString("COF_NAME");
> > float n = rs.getFloat("PRICE");
> > int rowNum = rs.getRow();
> > System.out.println(rowNum + ":\t" + s + "\t" + n);
> > } catch (SQLException sqlEx) { /* ignore */
> > System.out.println("print ResultSet failed");
> > }
> > }
> >
> > public static void forward(ResultSet rs) {
> > try {
> > System.out.println("--- Forward ---");
> > rs.beforeFirst();
> > while (rs.next()) {
> > print(rs);
> > }
> > } catch (SQLException sqlEx) { /* ignore */
> > System.out.println("print ResultSet failed");
> > }
> > }
> >
> > public static void backward(ResultSet rs) {
> > try {
> > System.out.println("--- Backward ---");
> > rs.afterLast();
> > while (rs.previous()) {
> > print(rs);
> > }
> > } catch (SQLException sqlEx) { /* ignore */
> > System.out.println("print ResultSet failed");
> > }
> > }
> >
> > public static void main(String args [])
> > throws Exception
> > {
> >
> > Connection conn = null;
> > Statement stmt = null;
> >
> > try {
> > // Load the mysql JDBC driver
> > Class.forName(driver).newInstance();
> >
> > // Connect to the database
> > Properties props = new Properties();
> > props.put("user", userName);
> > props.put("password", password);
> > props.put("loglevel", "0");
> > conn = DriverManager.getConnection(url, props);
> >
> > // Create a Statement
> > stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
> > ResultSet.CONCUR_UPDATABLE);
> >
> > DatabaseMetaData meta = conn.getMetaData();
> > System.out.println("DatabaseProductName: " +
> > meta.getDatabaseProductName());
> > System.out.println("DatabaseProductVersion: " +
> > meta.getDatabaseProductVersion());
> > System.out.println("DriverName: " +
> > meta.getDriverName());
> > System.out.println("DriverVersion: " +
> > meta.getDriverVersion());
> >
> > try {
> > stmt.executeUpdate("drop table coffees");
> > } catch (SQLException sqlEx) { /* ignore */
> > System.out.println("drop table failed");
> > }
> >
> > // create the table
> > String createTableCoffees = "create table coffees " +
> > "(COF_NAME VARCHAR(32) primary key, PRICE FLOAT)";
> > try {
> > stmt.executeUpdate(createTableCoffees);
> > } catch (SQLException sqlEx) { /* ignore */
> > System.out.println("create table failed");
> > }
> >
> > stmt.executeUpdate("insert into coffees " +
> > "VALUES ('Colombian', 7.
Re: [JDBC] [BUGS] JDBC getImortedKeys() getExportedKeys()
Patch Applied, Thanks, Dave On Mon, 2003-11-03 at 05:25, Kris Jurka wrote: > On Fri, 15 Aug 2003, Richard Froud wrote: > > > Please enter a FULL description of your problem: > > > > When reading database metadata for foreign keys using the JDBC > > DatabaseMetaData.getImportedKeys() and DatabaseMetaData.getExportedKeys() > > methods the ON UPDATE rule is returned as the ON DELETE rule. It is also > > correctly returned as the ON UPDATE rule. Therefore there is no way to > > access the ON DELETE rule. Consequenntly innaccurate representations of the > > database structure are obtained. > > Here is a patch for this. Additionally the on delete rule would not > return importedKeyRestrict because of a missing if statement. Also an > addition to the test suite is attached. > > Kris Jurka > > > __ > > ---(end of broadcast)--- > TIP 7: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [JDBC] [BUGS] BUG #1026: org.apache.commons.dbcp.DbcpException:
Tammy, are you building the jar from source? if so can you try running ant test ? also see my comments below Dave On Wed, 2003-12-24 at 09:32, Tammy Jones wrote: > > Kris Jurka wrote: > > > PostgreSQL version: 7.3.4 > > > > > > Description:org.apache.commons.dbcp.DbcpException: The connection > > > attempt failed because failed getting backend > > > > > > We are trying to install DSPACE with POSTGRES. When we run the ant > > > fresh_install command we get the following error. What could be causing a > > > org.apache.commons.dbcp.DbcpException: The connection attempt failed because > > > failed getting backend encoding? > > > > > > > Have you been able to establish a JDBC connection at all or is this error > > only with dspace? > I really haven't tried postgres with anything other than dspace. > > Could you enable logging on the server and see if that comes up with > > anything interesting? (Enable log_statement in postgresql.conf and > > restart the server making sure the output is going somewhere other than > > /dev/null) > > I enabled logging. The logging results are below with the query > results. > > What do you get from the results of the following queries when run in > > psql? > > > I assume that I am running the queries appropriately. The database > service had to be started because of copy paste problems, not because > of the queries below. Here are the results: > > SELECT version(); > $psql -d dspace -c "SELECT version();" you really should be getting something like ~/reiser/informix7.4/bin/psql isp -c "select version()" version -- PostgreSQL 7.4informix1.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) (1 row) and ~/reiser/informix7.4/bin/psql -d isp -c "select pg_encoding_to_char(1)" pg_encoding_to_char - EUC_JP (1 row) not SELECT ?? > SELECT > $ more logfile > 2003-12-24 09:21:12 LOG: database system was shut down at 2003-12-24 > 09:20:46 E > ST > 2003-12-24 09:21:12 LOG: checkpoint record is at 0/84FAA8 > 2003-12-24 09:21:12 LOG: redo record is at 0/84FAA8; undo record is > at 0/0; shu > tdown TRUE > 2003-12-24 09:21:12 LOG: next transaction id: 587; next oid: 25169 > 2003-12-24 09:21:12 LOG: database system is ready > 2003-12-24 09:21:44 LOG: query: begin; select getdatabaseencoding(); > commit > 2003-12-24 09:21:44 LOG: query: SELECT version(); > RESULT :c=0.00..0.01 :r=1 :w=0 > RESULT :c=0.00..0.01 :r=1 :w=0 > 2003-12-24 09:22:49 LOG: query: begin; select getdatabaseencoding(); > commit > 2003-12-24 09:22:49 LOG: query: SELECT version(); > RESULT :c=0.00..0.01 :r=1 :w=0 > RESULT :c=0.00..0.01 :r=1 :w=0 > > SELECT pg_encoding_to_char(1); > $ psql -d dspace -c "SELECT pg_encoding_to_char(1);" > SELECT > $ more logfile > 2003-12-24 09:25:28 LOG: database system was shut down at 2003-12-24 > 09:25:01 E > ST > 2003-12-24 09:25:28 LOG: checkpoint record is at 0/84FAE8 > 2003-12-24 09:25:28 LOG: redo record is at 0/84FAE8; undo record is > at 0/0; shu > tdown TRUE > 2003-12-24 09:25:28 LOG: next transaction id: 593; next oid: 25169 > 2003-12-24 09:25:28 LOG: database system is ready > 2003-12-24 09:25:33 LOG: query: begin; select getdatabaseencoding(); > commit > 2003-12-24 09:25:33 LOG: query: SELECT pg_encoding_to_char(1); > RESULT :c=0.00..0.01 :r=1 :w=0 > RESULT :c=0.00..0.01 :r=1 :w=0 > > SELECT getdatabaseencoding(); > $ psql -d dspace -c "SELECT getdatabaseencoding();" > SELECT > $ more logfile > 2003-12-24 09:26:46 LOG: database system was shut down at 2003-12-24 > 09:26:26 E > ST > 2003-12-24 09:26:46 LOG: checkpoint record is at 0/84FB28 > 2003-12-24 09:26:46 LOG: redo record is at 0/84FB28; undo record is > at 0/0; shu > tdown TRUE > 2003-12-24 09:26:46 LOG: next transaction id: 596; next oid: 25169 > 2003-12-24 09:26:46 LOG: database system is ready > 2003-12-24 09:26:55 LOG: query: begin; select getdatabaseencoding(); > commit > 2003-12-24 09:26:55 LOG: query: SELECT getdatabaseencoding(); > RESULT :c=0.00..0.01 :r=1 :w=0 > RESULT :c=0.00..0.01 :r=1 :w=0 > > Kris Jurka > > > > > > ---(end of broadcast)--- > > TIP 8: explain analyze is your friend > > > > > > > -- > Tammy Jones > > ANALYTICAL SERVICES & MATERIALS > NASA LaRC > 2 West Durand Street > Hampton, VA 23681 > > Mail Stop 185 > Building 1194, Room 106 > Phone: 4-8003 > Fax:4-8869 > > _ > "When your values are clear your decisions are easy" > -Walt Disney- > _ > ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister Your
Re: [JDBC] [BUGS] BUG #1026: org.apache.commons.dbcp.DbcpException:
Tammy, Sorry, I wasn't clear, ant test is for the jdbc driver. Either way, if you can't get psql to return version then there are problems. Does psql work in interactive mode, can you select anything? Dave On Wed, 2003-12-24 at 11:59, Tammy Jones wrote: > I am building dspace from source, however ant test does not work. I > get the following error: > $ ant test > Buildfile: build.xml > > BUILD FAILED > Target `test' does not exist in this project. > > > I tried running the psql commands just like below and still only get > SELECT as the response. > > Below is a snippit of our installation process that involved > postgres. Maybe it'll help shed some light. > > Notation > Throughout the course of this document we will used the following > notation: > > [postgres-src] – This is the source from which you will build and > install the PostgreSQL database system. We used > /usr/local/postgresql-7.3.4. > > [postgres] – The directory in which you will/have install(ed) > PostgreSQL. We used /usr/local/pgsql. > > [postgres-data] – This is the location of the PostgreSQL database, > which will then contain the data from DSpace. We used > /usr/local/pgsql/data. Note: that this directory must have rwx > permissions for the PostgreSQL user. > > > PostgreSQL > We used 7.3.4. > > > Pre-requisite Software: > gmake or make: Download the GNU Make binary file, which comes as a > .tar.gz compressed file. We located GNU Make at /usr/local/bin/make. > > gcc: Download the gcc binary file, which comes as a .tar.gz > compressed file. We located gcc at /usr/local/bin/gcc. > > readline: Download the readline binary file, which comes as a .tar.gz > compressed file. We located readline at /usr/local/bin/readline. > > Copy the libreadline library into /usr/lib and /usr/local/lib. > > JDBC: Download the JDBC drivers > athttp://jdbc.postgresql.org/download.html. We located the download > at /usr/local/jdbc. > > > Installation: > Note: DSpace comes packaged with a postgresql.jar file for an older > version of PostgreSQL. To make DSpace work with PostgreSQL 7.2.4 it > is necessary to replace their version of postgresql.jar with the new > one created with this installation. > > Note: You require Ant 1.5 in order to build PostgreSQL 7.2.4 using the > –-with-java option required to create the drivers for DSpace. > > Note: You must do the installation in bourne shell. > > > ·Create a user called postgres and a group of the same name. > > ·Login as postgres in order to do the installation. > > ·Configure the source: > > Go to the directory [postgres-src], and run the following command: > > ./configure --prefix=[postgres] > > –-enable-multibyte > > --enable-unicode > > --with-java > > ·make PostgreSQL: > > In [postgres-src] run the command: > > make > > ·Install PostgreSQL: > > In [postgres-src] run the command: > > make install > > ·Create the database: > > Use the following commands (you may be in any system directory > provided that you use the full path names of each directory): > > mkdir [postgres-data] > > [postgres]/bin/initdb –D [postgres-data] > > ·Copy the postgresql.jar file > > cp [postgres]/share/java [DSpace-src]/lib > > ·Place the libgcc library in the postgres library > > cp libgcc_s.so.1 [postgres]/lib/. > > ·Copy the JDBC driver jar file to postgres: > > cp jdbcDriver.jar [postgres]/share/java/. > > ·Edit the postgres configuration file, > [postgres]/data/postgresql.conf. to switch on the TCP/IP connections > and configure the port: > > Set the following configuration parameters: > > tcpip_socket=true > > port=5432 > > ·Set the following environment variables: > > PGDATA=[pgsql]/data > > PGPORT=5432 > > ·Start the database service: > > [postgres]/bin/postmaster –o "-i" -D /usr/local/pgsql/data > logfile > 2>&1 & > > > DSpace Installation > ·Create a DSpace user and a group of the same name, containing > that user. > > ·Log in as DSpace. > > ·Create the DSpace database and user for that database: > > Use the following commands in the directory [postgres]/bin: > > createuser –U postgres –d –A –P DSpace > > createdb –U DSpace DSpace –E UNICODE > > > > > Dave Cramer wrote: > > Tammy, > > > > are you building the jar from source? if so can you try running ant test > > ? > > also see my comme
Re: [JDBC] [BUGS] BUG #2060: Issue with Data base connection
It's interesting to note that *everyone* else using the JDBC driver
doesn't have this problem ?
Dave
On 23-Nov-05, at 2:44 PM, Kris Jurka wrote:
kalisetty manideep wrote:
[Backend reports "too many open connections"]
>
But I am 100% sure that its not the issue with the
code.
Do you know any Postgresql - JDBC driver, which is not
from Postgresql development group. I think JDBC driver
is not closing the connection even though I am closing
the connection.
I have no reason to believe that and you certainly haven't shown that.
Please refer to the DBACCESS file attached.
All this shows is the Connection being opened, not closed.
I've implemented an idea I got from rupa in #postgresql a while ago
about a way of logging leaked connections. I've added some code to
the Connection's finalize() method that prints some logging
information if the Connection was not closed. This is enabled by
using the new logUnclosedConnections URL parameter.
See the attached code for an example. I've put up a new jar that
contains this here: http://www.ejurka.com/pgsql/jars/km
import java.sql.*;
public class OpenConn {
public static void main(String args[]) throws Exception {
Class.forName("org.postgresql.Driver");
leakConnection();
System.gc();
}
private static void leakConnection() throws Exception {
Connection conn = DriverManager.getConnection("jdbc:postgresql://
localhost:5810/jurka?logUnclosedConnections=true","jurka","");
}
}
---(end of
broadcast)---
TIP 6: explain analyze is your friend
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [JDBC] [BUGS] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception
Thanks Tom. So an unsigned long won't fit inside a java long either, but hopefully it will never be necessary. That would be a huge number of changes. Dave Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Fri, Dec 21, 2012 at 11:47 AM, Tom Lane wrote: > zela...@amazon.com writes: > > The following bug has been logged on the website: > > Bug reference: 7766 > > Logged by: Zelaine Fong > > Email address: zela...@amazon.com > > PostgreSQL version: 8.4.0 > > Operating system: Linux > > Description: > > > The updateCount field in the ResultHandler interface in Java is defined > as > > an int rather than long. Therefore, if you prepare and execute an > update, > > delete, or insert statement that affects more than 2^32 rows, you will > get > > the following exception: > > > Unable to interpret the update count in command completion tag > > Forwarding this to pgsql-jdbc list. FWIW, guys, the backend currently > thinks that execution counts are unsigned ints. So I surmise that the > problematic update count was actually between 2^31 and 2^32. We might > get around to changing it to unsigned long someday ... > > regards, tom lane > > > -- > Sent via pgsql-jdbc mailing list (pgsql-j...@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc >
Re: [JDBC] [BUGS] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception
Ok, this is much more difficult than I thought. Turns out that there are at least two interfaces that expect an int not a long. BatchUpdateException executeBatch I'm thinking the only option here is to report INT_MAX as opposed to failing. Thoughts ? Dave Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Fri, Dec 21, 2012 at 3:17 PM, Tom Lane wrote: > Dave Cramer writes: > > So an unsigned long won't fit inside a java long either, but hopefully it > > will never be necessary. That would be a huge number of changes. > > I think we'll all be safely dead by the time anybody manages to process > 2^63 rows in one PG command ;-). If you can widen the value from int to > long on the Java side, that should be sufficient. > > regards, tom lane >
Re: [JDBC] [BUGS] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception
Yes, that seems like a much better approach. I'm guessing SUCCESS_NO_INFO is < 0 and an int. I can't wait for the error reports (arguments) Dave Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Fri, Jan 11, 2013 at 10:32 AM, Stefan Reiser wrote: > One thought: > > What about returning Statement.SUCCESS_NO_INFO as it says in > http://docs.oracle.com/javase/**6/docs/api/java/sql/** > BatchUpdateException.html#**getUpdateCounts%28%29<http://docs.oracle.com/javase/6/docs/api/java/sql/BatchUpdateException.html#getUpdateCounts%28%29> > and > http://docs.oracle.com/javase/**6/docs/api/java/sql/Statement.** > html#executeBatch%28%29<http://docs.oracle.com/javase/6/docs/api/java/sql/Statement.html#executeBatch%28%29> > > ? > > It seems better to report no number at all rather than a number (INT_MAX) > that is known to be wrong. > > > > Dave Cramer schrieb: > >> Ok, this is much more difficult than I thought. >> >> Turns out that there are at least two interfaces that expect an int not a >> long. >> >> BatchUpdateException >> executeBatch >> >> I'm thinking the only option here is to report INT_MAX as opposed to >> failing. >> >> Thoughts ? >> >> Dave >> >> >> Dave Cramer >> >> dave.cramer(at)credativ(dot)ca >> http://www.credativ.ca >> >> >> On Fri, Dec 21, 2012 at 3:17 PM, Tom Lane > t...@sss.pgh.pa.us>> wrote: >> >> >> Dave Cramer mailto:p...@fastcrypt.com>> writes: >> > So an unsigned long won't fit inside a java long either, but >> hopefully it >> > will never be necessary. That would be a huge number of changes. >> >> I think we'll all be safely dead by the time anybody manages to >> process >> 2^63 rows in one PG command ;-). If you can widen the value from >> int to >> long on the Java side, that should be sufficient. >> >> regards, tom lane >> >> >> >
Re: [JDBC] [BUGS] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception
Ok, I've pushed this fix into master On Fri, Jan 11, 2013 at 10:38 AM, Dave Cramer wrote: > SUCCESS_NO_INFO Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca
Re: [JDBC] [BUGS] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception
Good points to both. Thank you both for reviewing.
Dave
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On Fri, Jan 11, 2013 at 12:36 PM, Stefan Reiser wrote:
> Kris Jurka schrieb:
>
>
>> On Fri, 11 Jan 2013, Dave Cramer wrote:
>>
>> Ok, I've pushed this fix into master
>>>
>>> You've made any failure to parse the affected row count return
>> SUCCESS_NO_INFO. Shouldn't you change the integer parsing to a long
>> parsing and only modify the response if the value is > INT_MAX while still
>> throwing an exception if we get something that is truly undecipherable?
>>
>> Kris Jurka
>>
>>
>> Dave,
> I'm completely unfamiliar with the driver's code, so I better won't take
> part in the further discussion -- just one thing: Now "insert_oid" won't be
> assigned correctly when the assignment of update_count fails:
>
> [QueryExecutorImpl.java]
> try
> {
> update_count = Integer.parseInt(status.**substring(1 +
> status.lastIndexOf(' ')));
> if (status.startsWith("INSERT"))
> insert_oid = Long.parseLong(status.**substring(1 +
> status.indexOf(' '),
> status.lastIndexOf(' ')));
> }
> catch (NumberFormatException nfe)
> {
> update_count=Statement.**SUCCESS_NO_INFO;
> }
>
> better be something like this: ?
>
> try
> {
> update_count = Integer.parseInt(status.**substring(1 +
> status.lastIndexOf(' ')));
> }
> catch (NumberFormatException nfe)
> {
> update_count=Statement.**SUCCESS_NO_INFO;
> }
> try {
> if (status.startsWith("INSERT"))
> insert_oid = Long.parseLong(status.**substring(1 +
> status.indexOf(' '),
> status.lastIndexOf(' ')));
> } catch ( ...
> // don't know what expected behaviour should be ...
> }
>
> regards
> Stefan Reiser
>
Re: [JDBC] [BUGS] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception
Peter, Can you be more specific about your concerns ? Dave Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Sat, Jan 12, 2013 at 3:25 AM, Péter Kovács wrote: > And what about > http://docs.oracle.com/javase/6/docs/api/java/sql/Statement.html#getUpdateCount()? > > P. > On Jan 11, 2013 2:20 PM, "Dave Cramer" wrote: > >> Ok, this is much more difficult than I thought. >> >> Turns out that there are at least two interfaces that expect an int not a >> long. >> >> BatchUpdateException >> executeBatch >> >> I'm thinking the only option here is to report INT_MAX as opposed to >> failing. >> >> Thoughts ? >> >> Dave >> >> >> Dave Cramer >> >> dave.cramer(at)credativ(dot)ca >> http://www.credativ.ca >> >> >> On Fri, Dec 21, 2012 at 3:17 PM, Tom Lane wrote: >> >>> Dave Cramer writes: >>> > So an unsigned long won't fit inside a java long either, but hopefully >>> it >>> > will never be necessary. That would be a huge number of changes. >>> >>> I think we'll all be safely dead by the time anybody manages to process >>> 2^63 rows in one PG command ;-). If you can widen the value from int to >>> long on the Java side, that should be sufficient. >>> >>> regards, tom lane >>> >> >>
Re: [JDBC] [BUGS] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception
Well since it returns an int and it's impossible to return > 2^32 in an int then we will be returning Statement.SUCCESS_NO_INFO Dave Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Sat, Jan 12, 2013 at 4:27 AM, Péter Kovács wrote: > I mean what value this method will return for an update statement > affecting, say, five billion rows? But I may misunderstand something. > On Jan 12, 2013 9:57 AM, "Dave Cramer" wrote: > >> Peter, >> >> Can you be more specific about your concerns ? >> >> Dave >> >> Dave Cramer >> >> dave.cramer(at)credativ(dot)ca >> http://www.credativ.ca >> >> >> On Sat, Jan 12, 2013 at 3:25 AM, Péter Kovács < >> peter.dunay.kov...@gmail.com> wrote: >> >>> And what about >>> http://docs.oracle.com/javase/6/docs/api/java/sql/Statement.html#getUpdateCount()? >>> >>> P. >>> On Jan 11, 2013 2:20 PM, "Dave Cramer" wrote: >>> >>>> Ok, this is much more difficult than I thought. >>>> >>>> Turns out that there are at least two interfaces that expect an int not >>>> a long. >>>> >>>> BatchUpdateException >>>> executeBatch >>>> >>>> I'm thinking the only option here is to report INT_MAX as opposed to >>>> failing. >>>> >>>> Thoughts ? >>>> >>>> Dave >>>> >>>> >>>> Dave Cramer >>>> >>>> dave.cramer(at)credativ(dot)ca >>>> http://www.credativ.ca >>>> >>>> >>>> On Fri, Dec 21, 2012 at 3:17 PM, Tom Lane wrote: >>>> >>>>> Dave Cramer writes: >>>>> > So an unsigned long won't fit inside a java long either, but >>>>> hopefully it >>>>> > will never be necessary. That would be a huge number of changes. >>>>> >>>>> I think we'll all be safely dead by the time anybody manages to process >>>>> 2^63 rows in one PG command ;-). If you can widen the value from int >>>>> to >>>>> long on the Java side, that should be sufficient. >>>>> >>>>> regards, tom lane >>>>> >>>> >>>> >>
Re: [JDBC] [BUGS] BUG #7766: Running a DML statement that affects more than 4 billion rows results in an exception
Well my bet is the actual value of Statement.SUCCESS_NO_INFO is negative. My understanding of the code is that it will not throw the exception unless there is a real parse error. Dave Dave Cramer dave.cramer(at)credativ(dot)ca http://www.credativ.ca On Sat, Jan 12, 2013 at 5:06 AM, Péter Kovács wrote: > But being designed for batch updates, is Statement.SUCCESS_NO_INFO > appropriate in the context of plain updates? I think the value of > Statement.SUCCESS_NO_INFO is supposed to be opaque. What if it happens to > be 3, for example? Client code will think three rows have been affected. > > Conversely, if you plan to throw a batch update exception for all > successful plain updates affecting too large amount of rows, client code is > unlikely to be prepared to handle batch update exceptions for plain > updates. (I feel there is also a more general usability problem with the > JDBC API for batch updates expecting client code to expect exceptions to be > thrown for successful executions. But I may be misunderstanding > something...) > > Peter > On Jan 12, 2013 10:41 AM, "Dave Cramer" wrote: > >> Well since it returns an int and it's impossible to return > 2^32 in an >> int then we will be returning Statement.SUCCESS_NO_INFO >> >> Dave >> >> Dave Cramer >> >> dave.cramer(at)credativ(dot)ca >> http://www.credativ.ca >> >> >> On Sat, Jan 12, 2013 at 4:27 AM, Péter Kovács < >> peter.dunay.kov...@gmail.com> wrote: >> >>> I mean what value this method will return for an update statement >>> affecting, say, five billion rows? But I may misunderstand something. >>> On Jan 12, 2013 9:57 AM, "Dave Cramer" wrote: >>> >>>> Peter, >>>> >>>> Can you be more specific about your concerns ? >>>> >>>> Dave >>>> >>>> Dave Cramer >>>> >>>> dave.cramer(at)credativ(dot)ca >>>> http://www.credativ.ca >>>> >>>> >>>> On Sat, Jan 12, 2013 at 3:25 AM, Péter Kovács < >>>> peter.dunay.kov...@gmail.com> wrote: >>>> >>>>> And what about >>>>> http://docs.oracle.com/javase/6/docs/api/java/sql/Statement.html#getUpdateCount()? >>>>> >>>>> P. >>>>> On Jan 11, 2013 2:20 PM, "Dave Cramer" wrote: >>>>> >>>>>> Ok, this is much more difficult than I thought. >>>>>> >>>>>> Turns out that there are at least two interfaces that expect an int >>>>>> not a long. >>>>>> >>>>>> BatchUpdateException >>>>>> executeBatch >>>>>> >>>>>> I'm thinking the only option here is to report INT_MAX as opposed to >>>>>> failing. >>>>>> >>>>>> Thoughts ? >>>>>> >>>>>> Dave >>>>>> >>>>>> >>>>>> Dave Cramer >>>>>> >>>>>> dave.cramer(at)credativ(dot)ca >>>>>> http://www.credativ.ca >>>>>> >>>>>> >>>>>> On Fri, Dec 21, 2012 at 3:17 PM, Tom Lane wrote: >>>>>> >>>>>>> Dave Cramer writes: >>>>>>> > So an unsigned long won't fit inside a java long either, but >>>>>>> hopefully it >>>>>>> > will never be necessary. That would be a huge number of changes. >>>>>>> >>>>>>> I think we'll all be safely dead by the time anybody manages to >>>>>>> process >>>>>>> 2^63 rows in one PG command ;-). If you can widen the value from >>>>>>> int to >>>>>>> long on the Java side, that should be sufficient. >>>>>>> >>>>>>> regards, tom lane >>>>>>> >>>>>> >>>>>> >>>> >>
