7.3 top-of-tree compilation error on OSX

From: Drew Wilson <amw(at)speakeasy(dot)net>
To: pgsql-jdbc(at)postgresql(dot)org
Subject: 7.3 top-of-tree compilation error on OSX
Date: 2002-10-11 17:02:37
Message-ID: 3E887245-DD3B-11D6-BBDD-00039362D52E@speakeasy.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

I'm getting a compilation error when trying to build the latest pgsql
sources.

Here's ant's error log:
examples:
[javac] Compiling 8 source files to
/Volumes/data/Users/drew/sources/TAOWO/tools/pgsql/src/interfaces/jdbc/
build
[javac]
/Volumes/data/Users/drew/sources/TAOWO/tools/pgsql/src/interfaces/jdbc/
org/postgresql/jdbc1/AbstractJdbc1Connection.java:269:
encode(java.lang.String,java.lang.String,java.lang.String) in
org.postgresql.util.MD5Digest cannot be applied to
(java.lang.String,java.lang.String,byte[])
[javac]
byte[] digest = MD5Digest.encode(PG_USER, password, md5Salt);
[javac]
^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
[javac] 1 error

Sorry, I couldn't figure out the problem from looking at the two files,
org/postgresql/jdbc1/AbstractJdbc1Connection.java and
org/postgresql/util/MD5Digest.java.

FYI - I'm building on Mac OS X 10.2, with the following configuration.
./configure
--prefix=/Volumes/data/Users/drew/sources/TAOWO/buildresults/postgres
--bindir=/Volumes/data/Users/drew/sources/TAOWO/buildresults/bin/
--enable-recode --with-java --without-readline --enable-syslog
--enable-unicode-conversion --enable-multibyte --enable-cassert
--enable-debug.

Thanks for any help,

Drew

On Friday, October 11, 2002, at 09:42 AM, Barry Lind wrote:

>
>
> Aaron Mulder wrote:
>> You may be able to configure your app server database pools to
>> cache PreparedStatements. Some version of JBoss and WebLogic support
>> this, at any rate. The idea is that just like connections aren't
>> really
>> closed when you call close (just returned to the pool), PSs aren't
>> really
>> closed when you call close (just kept in a cache for the connection).
>> This would let you take advantage of server side PSs in an app >> server
>> environment.
>> The danger is that if each connection has a high PS cache size, you
>> can run into problems like "too many open cursors" on Oracle (when 50
>> connections each try to cache 50 PSs or whatever).
>
> Oracle's max open cursors is per connection. So as long as it is set
> higher than the size of the statement cache you should be ok. I also
> beleive that in recent versions of the oracle jdbc driver, the driver
> does this statement caching automatically. It shouldn't be too
> difficult to add statement caching to the postgres jdbc driver if we
> thought it would be a good idea.
>
>> I'm not sure whether PostgreSQL would complain or not. Does it
>> support multiple open PreparedStatements per Connection? And if so,
>> are there any backend limits to the total number of open server side
>> PSs?
>
> Yes it does support mulitple server side prepared statements. There
> isn't any limit on the backend (other than available memory) on the
> number.
>
>
>> Aaron
>
> --Barry
>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Aaron Mulder 2002-10-11 17:05:37 Re: Out of memory error on huge resultset
Previous Message Barry Lind 2002-10-11 16:55:57 Re: Out of memory error on huge resultset