tr
things have gotten a little worse...i recently upgraded to postgresql 7.1
and now i am seeing this behavior even WITHOUT large objects. it happens
much less frequently without LOs, but it still happens. i never saw this
behavior in 7.0. are you seeing the same behavior?
i guess i don't
I have applied this patch by manually fixing the word wrapping. Thanks.
Bruce, for info:
Hi Peter,
I've revised the italian translation of error messages
in the PostgreSQL JDBC driver.
Regards,
Daniele Arduini
# This is the italian version of some errors. Errors not in this file
#
* Tom Lane [EMAIL PROTECTED] wrote:
|
| Of these #3 seems like the solution that will emerge in the long term
| anyway; but do we have candidate patch-meisters now?
|
| Comments, better ideas, nominations, volunteers?
I would like to nominate Barry Lind as he has been doing great work for a
I really don't understand why this is happening either.
my current guess is that there is something going on
in the way we are reusing connections. To answer your
question I don't think there is any relationship between the
2 connections just that after the first one is corrupted
I use the
tom
i do agree that since everyone isn't complaining, the problem is likely in
my code. the odd thing is that i wasn't seeing this behavior with the 7.0
stuff, only with the 7.1. (i was having the fastpath problem with 7.0, but
that's a different issue.)
i'm looking...
thanks
chris
the 7.1 driver that i am using was downloaded from
http://jdbc.fastcrypt.com. is that the right spot?
chris
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 06, 2001 12:40 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject:
chris markiewicz [EMAIL PROTECTED] writes:
i do agree that since everyone isn't complaining, the problem is likely in
my code. the odd thing is that i wasn't seeing this behavior with the 7.0
stuff, only with the 7.1.
Hmm. Are you using the JDBC driver that was released with 7.1? That
trm
i have been able to successfully avoid the problem for the last 20 minutes
or so...my connection pooling system calls commit() on connections before
returning them to the available pool (even if they were already
'committed')...i added a conditional to check whether or not it was already
On Mon, 3 Sep 2001 22:01:17 -0500, you wrote:
public boolean isWritable(int column) throws SQLException
{
if (isReadOnly(column))
return true;
else
return false;
}
The author probably intended:
public boolean isWritable(int column) throws
On 04 Sep 2001 13:22:33 -0400, Dave Cramer wrote:
Isn't the JDBC 2 driver also an implementation of JDBC 1?
Yes, it is, but many of the libraries, and methods which are used in
version 2 of the driver aren't available in jdk1 so it won't compile or
run.
Ah, I see. And I assume we support JDBC 1
Dave,
I agree with you, and it seems that much of the existing jdbc code is
formated that way. But before starting a thread on what everybody
prefers as their java format, let me first ask the question:
Should the jdbc java code use the same formatting as the C code?
If the answer is yes,
the 7.1 driver that i am using was downloaded from
http://jdbc.fastcrypt.com. is that the right spot?
Yep, that is the one.
---
chris
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent:
On Thu, Sep 06, 2001 at 09:51:19AM -0700, Barry Lind wrote:
Should the jdbc java code use the same formatting as the C code?
IMHO, yes: for consistency and because it is, at the moment, part of the
main package.
Liam
--
Liam Stewart :: Red Hat Canada, Ltd. :: [EMAIL PROTECTED]
I've found after using a CMP J2EE entity bean, along with the 7.1.3 jdbc
driver, queries return the entire char field back while using char(), but
varchar returns just the value of the field back.
for example,
create table test_table(
id integer primary key not null,
name varchar(255)
);
vs.
Hmm.. ok.
Just I usually prefer using fixed field lengths as queries tend to be
significantly faster. Also, you can use them in indexes.
I find it strange that that would be the case...
And it leads me to wonder how you would represent an ending space in a
field,
for example
insert into
Well, that's how it works in the postgres documentation... I could have
sworn that I've never encountered this in other databases.. Must have a bad
memory.
Guess I'll just trim everything.
-Jeff
Hmm.. ok.
Just I usually prefer using fixed field lengths as queries tend to be
significantly
[EMAIL PROTECTED] writes:
Just I usually prefer using fixed field lengths as queries tend to be
significantly faster. Also, you can use them in indexes.
You are making assumptions based on other databases that are not
relevant to Postgres.
And it leads me to wonder how you would represent an
I also built a linked list of available connections today
and my problem has completly gone away. I have an intensly
threaded app and it has been running now for several hours
doing 1000's of inserts without the problem I was having
before. I don't know how dave implemented his list but
I have
On Sun, 02 Sep 2001 23:41:49 +0200, you wrote:
On a busy server, serving web pages using tomcat and apache, I
get this error sometimes:
java.net.SocketException: errno: 48, error: Address already in
use for fd: 168
at java.net.PlainSocketImpl.socketConnect(Native
Method)
This means the
I am willing to lend a hand if required
Dave
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Bruce Momjian
Sent: September 6, 2001 4:08 PM
To: Rene Pijlman
Cc: Tom Lane; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [JDBC] JDBC patch procedures
On Fri, 07 Sep 2001 02:37:36 +0200, I wrote:
Is your application opening and closing PostgreSQL
connections at such a high rate?
Or, I should add, is it opening that many connections?
Regards,
René Pijlman [EMAIL PROTECTED]
---(end of
I'm not a JDBC expert, but this is pretty much the way I'd expect it to
work. If you a have fixed length field, then the field should return that
many characters. The varchar implies it's variable length, so trailing
spaces would then not be included.
David
---(end of
I can easily get around this using .trim(), but I'm wondering if that
should be in the jdbc driver itself (as I'll have to go through a bit of
code looking for string values being returned).
char() is fixed length, varchar isn't.
Or is this something in the database software itself that
Well, if it is that easy, I can do it. Patch attached and applied.
On Mon, 3 Sep 2001 22:01:17 -0500, you wrote:
public boolean isWritable(int column) throws SQLException
{
if (isReadOnly(column))
return true;
else
return false;
}
The
I believe this was done a while ago. (It looks like it was patched on
Aug 17 by a patch from Rene).
thanks,
--Barry
Bruce Momjian wrote:
Can someone tackles this and supply a patch?
Would some JDBC hacker develop a patch for the following issue? The
change is just barely large enough
On Thu, 06 Sep 2001 14:30:49 -0400, you wrote:
Ultimately it's the committer's responsibility
to have confidence that the patch he applies is good; if he doesn't
feel competent to check it himself, he should call for more reviewers.
If he does feel sure about it, there's no need for
On Thu, 6 Sep 2001 14:26:49 -0400 (EDT), you wrote:
Well, if it is that easy, I can do it. Patch attached and applied.
On Mon, 3 Sep 2001 22:01:17 -0500, you wrote:
public boolean isWritable(int column) throws SQLException
{
return !isReadOnly(column);
}
Actually, I
Change applied. Thanks.
On Thu, 6 Sep 2001 14:26:49 -0400 (EDT), you wrote:
Well, if it is that easy, I can do it. Patch attached and applied.
On Mon, 3 Sep 2001 22:01:17 -0500, you wrote:
public boolean isWritable(int column) throws SQLException
{
return
Chris,
I'm curious; why are you using a hashtable for available connections,
and how do you use it?
I have been using a connection pool that uses a linked list, in LIFO
mode to store available connections.
I can donate the pool code if need be, it has been running for over a
year with no
29 matches
Mail list logo
