"Homayoun Yousefi'zadeh" <[EMAIL PROTECTED]> writes:
> Thanks for the response. I actually went thru
> the full exercise when I was compiling Tomcat
> engine with Ant. Every thing seems to be set up
> properly. This is a part od /etc/profile file
> that shows the settings of environmental variabl
Yes, and also rerun ./configure --with-java < ... > after you set
JAVA_HOME in your shell environment.
Norm
--
Norman Clarke
Combimatrix Corp Software Development
Harbour Pointe Tech Center
6500 Harbour Heights Pkwy, Suite 301
Mukilteo, WA 98275
tel: 425.49
Doug McNaught wrote:
>> I did what you suggested and nothing changed.
>> Actually, JDBC problem seems to be ant related
>> as it did not exist w/ version 7.0.3.
>
>
> You might want to double-check that JAVAHOME (sp?) is set before you
> make. I had problems building with Ant until I figured
I'd be happy to see during initial setup a few questions go by that would
size the underlying OS properly as well. We all do the same things with a
new system, increase filesystem limits etc... Some of these options (on a
dedicated postgresql) are gimme's. Why not do them once upfront, prompt the
"Homayoun Yousefi'zadeh" <[EMAIL PROTECTED]> writes:
> I did what you suggested and nothing changed.
> Actually, JDBC problem seems to be ant related
> as it did not exist w/ version 7.0.3.
You might want to double-check that JAVAHOME (sp?) is set before you
make. I had problems building with A
In article <[EMAIL PROTECTED]>, "Peter Galbavy"
<[EMAIL PROTECTED]> wrote:
> This information would help us decide whether to use an RC as a
> development platform, moving to release later when we are ready to test
> final work.
Peter,
For what it's worth, I've been using 7.1beta? and RC? in
de
Charlie Derr wrote:
> This sounds like the problem with the version of gcc
> that is included with rh7.0
>
> If you don't want to upgrade gcc to a newer version,
> I think you can fix the problem by "mv"ing gcc to brokengcc
> and then creating creating a new symlink gcc to kgcc. Redhat
>
Charlie Derr wrote:
> This sounds like the problem with the version of gcc that is included with
> rh7.0
>
> If you don't want to upgrade gcc to a newer version, I think you can fix the
> problem by "mv"ing gcc to brokengcc and then creating creating a new symlink
> gcc to kgcc. Redhat included
An excellent idea.
I suspect you'll get a biased resonse from the -hackers folks. This really
is an excellent idea.
Those options cover I think the main scenarios, with the first two options
being the most important. Ideally you'd basically sample server specs
(speed, # of procs, mem etc) and se
At 1:50 AM -0400 4/6/01, Tom Lane wrote:
>"Henry B. Hotz" <[EMAIL PROTECTED]> writes:
> > Bottom line: 7.1RC1 passes most of the regression tests on
> > NetBSD/macppc.
>
>The only thing that surprised me here was all of the warnings from
>libreadline calls:
>
> >> tab-complete.c: In function `ini
Hi,
My generic problem is performance when copying very large amounts of data to a db from
multiple clients.
I am writing a C program on Linux Redhat6.2 that accesses a 7.0.3 database using
libpq. I
would like to be able to do a printf through STDOUT (or another file pointer) TO the
database
After v7.1 is released ... ?
On Mon, 9 Apr 2001, Peter Eisentraut wrote:
> Excessively long values are currently silently truncated when they are
> inserted into char or varchar fields. This makes the entire notion of
> specifying a length limit for these types kind of useless, IMO. Needless
On Mon, Apr 09, 2001 at 09:20:42PM +0200, Peter Eisentraut wrote:
> Excessively long values are currently silently truncated when they are
> inserted into char or varchar fields. This makes the entire notion of
> specifying a length limit for these types kind of useless, IMO. Needless
> to say,
Excessively long values are currently silently truncated when they are
inserted into char or varchar fields. This makes the entire notion of
specifying a length limit for these types kind of useless, IMO. Needless
to say, it's also not in compliance with SQL.
How do people feel about changing t
> Hi Bruce,
>
> My thought on this is more for an "overall effect".
>
> Down The Track (i.e. in a few versions or so) I'm thinking, rightly or
> wrongly, that PostgreSQL will become Very Good at tuning itself.
>
> It would be a good thing if PostgreSQL could know just how fair it can
> play in
Mathijs Brands wrote:
>
>
> If you want to start running your production machine in august, it would
> be a very good idea to start using 7.1 now, since the stable release will
> most likely be out before then (probably april or early may).
>
> You seem to be using the Cygnus version of GCC. I'm
I can imagine some people wanting this. However, 7.1 has new deadlock
detection code, so I would you make a 7.1 version and send it over. We
can get it into 7.2. I think we need a SET variable, and it should
default to OFF.
Good idea. Thanks.
> Hi,
>
> I implement additional server functio
DISCLAIMER: don't take this as MySQL flaming (it isn't) or personally, this
are just my observations on an application, not a benchmark.
Today I tried a quite simple, mostly write database (HTTP logging).
* Postgres peaked at 709 inserts/sec (committed after 3 seconds or 100
inserts, whichever
If you can't handle the SET variable stuff, we can do it over here.
Thanks.
> Hi,
>
> I implement additional server functionality. Currently (v7.0.3), executing
> SQL update statement on the same
> row from inside two different processess results in blocking second process
> to the end of tran
Hi Bruce,
My thought on this is more for an "overall effect".
Down The Track (i.e. in a few versions or so) I'm thinking, rightly or
wrongly, that PostgreSQL will become Very Good at tuning itself.
It would be a good thing if PostgreSQL could know just how fair it can
play in regards to the ser
Hi,
I implement additional server functionality. Currently (v7.0.3), executing
SQL update statement on the same
row from inside two different processess results in blocking second process
to the end of transaction in
the first one. In real OLTP application second process can't wait too long.
Afte
I like this. Ensure that tips can be dumped into a log file --
preferably separate from the main one -- so it can be run on a live
system for a short period of time, recorded then analyzed later.
--
Rod Taylor
There are always four sides to every story: your side, their side, the
truth, and what
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 07 April 2001 15:24
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [pgAdmin-hackers] PL/pgSQL IDE project
>
>
> Hello all,
>
> I would like to inform you all that I am currently working on th
Hi,
i implement additional server functionality. Currently (v7.0.3), executing
SQL update statement on the same
row from inside two different processess results in blocking second process
to the end of transaction in the first one.
In real OLTP application second process can't wait too long. Afte
Zeugswetter Andreas SB writes:
> > However, 7.1beta6 to 7.1rc4 to 7.1.0 would be an ok
> > progression, as 7.1 < 7.1.0, I think (saying that without having tested it could be
> > dangerous :-)).
>
> I like this 7.1.0, it would also help to clarify what exact version is at hand.
> People tend
Lamar Owen writes:
> > You're still shipping old jar files. You could build them from the source
> > package.
>
> With which JDK? As Red Hat doesn't ship a _standard_ JDK, which one is
> appropriate? Or, what is the _standard_ JDK?
There is no standard JDK, in the same sense as there is no sta
Justin Clift writes:
> When we get around to PostgreSQL's self-tuning ability being actively
> developed (and I think Bruce has done some of the very start with his
> monitor program), perhaps having a compile time option to set the
> default for the server, and a runtime option in case it change
Nat Irons writes:
> Regression tests for Yellow Dog Linux (PPC RedHat derivative) failed all
> over the place with 7.0.3. Passed smoothly with 7.1RC3, though. I've
> got details if anybody's curious.
Probably no one curious since PPC support is one of the things that were
fixed in 7.1. :-)
-
> I have in my posession a HP9000/433s box. It doesn't have an OS on it
> yet, but will probably have NetBSD 1.5 on it soon. Do we need PG
> tested on it?
Yes!
> This is a 33Mhz MC68040 with 128Meg RAM...
Better start now, it will take a while ;)
- Thomas
--
Bruce,
Problem is the use of heap_drop_with_catalog().
* heap_drop_with_catalog - removes all record of named
relation from catalogs
*
* 1) open relation, check for existence, etc.
* 2) remove inheritance information
* 3) r
> Hi all,
>
> On Sun, 8 Apr 2001, The Hermit Hacker wrote:
>
> > If, by Friday, April 13th, there have been no bugs reported, all that will
> > happen is that rc4 will get renamed as the official release, no
> > repackaging or anything ...
>
> Was hoping that I'd have some time to get around to
Hi all,
On Sun, 8 Apr 2001, The Hermit Hacker wrote:
> If, by Friday, April 13th, there have been no bugs reported, all that will
> happen is that rc4 will get renamed as the official release, no
> repackaging or anything ...
Was hoping that I'd have some time to get around to it before now, bu
On Mon, 9 Apr 2001, Henshall, Stuart - WCP wrote:
> When I downlaod a full tarball I want it all, I'm greedy like that.
> ;)
> If it is to be split up as standard I believe problems will arise with
> different versions being used together (by me most likley...). Also IMHO it
> will not nece
Oliver Elphick wrote:
> R = 82
> b = 98
This is a very small problem of having capital R and lowercase b that I
believe can be taken into account in the development of 7.2.
> As I suggested in another mail, let us switch to using even minor
> numbers for releases and odd ones for development:
When I downlaod a full tarball I want it all, I'm greedy like that.
;)
If it is to be split up as standard I believe problems will arise with
different versions being used together (by me most likley...). Also IMHO it
will not necessarily be relised the docs have not been down loaded which
> However, 7.1beta6 to 7.1rc4 to 7.1.0 would be an ok
> progression, as 7.1 < 7.1.0, I think (saying that without having tested it could be
> dangerous :-)).
I like this 7.1.0, it would also help to clarify what exact version is at hand.
People tend to use shorthands like 7.1 to refer to an
36 matches
Mail list logo
