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 und
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
This does look good,
I personally prefer more whitespace
After ( and , as well as moving the opening brace to the next line.
Public int foo(int x,int y){
x=y;
}
Turns into
Public int foo( int x, int y )
{
x = y;
}
I find this easier to read.
Comments?
Dave
-Origina
* 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
l
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 secon
that's a good point...when this error occurs, i suppose the connection is
defunct and any transaction is already lost.
chris
-Original Message-
From: admin [mailto:admin]On Behalf Of Antonio Fiol Bonnin
Sent: Thursday, September 06, 2001 11:47 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTE
I understand.
However, doesn't the exception automatically do some kind of rollback? I can't
remember where I read such a thing...
Antonio
chris markiewicz wrote:
> antonio
>
> thanks. it actually does apply to some degree. i have noticed that rolling
> back the connection will sometimes pre
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
-Orig
new info...maybe it's too early to say, but it seems that i only have this
problem with 7.1...i just went back to 7.0 db and jdbc driver and now i am
running without incident...
t.r. - what are you running?
have any connection parameters changed? is there anything i need to change
in order to u
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: Re
"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? Tha
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
co
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) throw
I am in the process of rewriting my connection pooling object.
I'll share the results when i am finished later today I suspect.
How are you determining whether a transaction is active?
getAutoCommit?
-Original Message-
From: chris markiewicz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, Sept
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 JD
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, t
> 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]]
>
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 na
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
> significant
<[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 represen
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 mean
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 (Re:
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 broadcast)-
On Thu, 6 Sep 2001 07:06:29 -0400, you wrote:
>Public int foo(int x,int y){
> x=y;
>}
>
>Turns into
>
>Public int foo( int x, int y )
>{
> x = y;
>}
>
>
>I find this easier to read.
I agree. This is my preference as well in Java.
Regards,
René Pijlman <[EMAIL PROTECTED]>
--
Added to TODO:
* -Make binary interface for TOAST columns (base64)
* Make file in/out interface for TOAST columns, similar to large object
interface (force out-of-line storage and no compression)
> This is what I think needs to be done wrt large objects and binary
AFAIR,
I simply wrap the sql connection for ease of handling, and then put
available connections in the linked list. When I want one I remove it
from the linked list, and put it into a hashtable, keyed by the toString
method on the connection.
When it is returned, I remove it from the hash table
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 th
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 fals
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 that I don't want to commit untested
> code for it --- but not having a Java development environment at hand,
> I can't test the updated code.
Thanks for the votes of confidence. I am willing to take on the
responsibility if the core committee agrees.
thanks,
--Barry
Rene Pijlman wrote:
> On 06 Sep 2001 14:18:09 +0200, Gunnar Rønning wrote:
>
>>* Tom Lane <[EMAIL PROTECTED]> wrote:
>>| Of these #3 seems like the solution that will e
Looks good.
--Barry
Dave Cramer wrote:
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Dave Cramer
> Sent: September 4, 2001 1:21 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JDBC] Read transactions don't work on 7.0.x db's 2nd patch
>
>
> Here
Barry Lind <[EMAIL PROTECTED]> writes:
> I believe this was done a while ago. (It looks like it was patched on
> Aug 17 by a patch from Rene).
Looking again, getTables() seems to be fixed, but there is still an
unpatched reference to pg_description in getColumns(), in both
jdbc1 and jdbc2.
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
> 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);
>> }
Act
Dave Harkness wrote:
> At 12:41 PM 9/5/2001, Joseph Shraibman wrote:
>
>> new patch:
>
>
> There still seems to be an error with the same if-block.
>
> ! if (index>=-rows.size())
> ! internalIndex=rows.size()+index;
>
> becomes
>
> ! if (index > -rows_size)
> ! inte
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
> >> {
> >>
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 probl
42 matches
Mail list logo
