so it isn't a "fictitous crowd" that is going with the smaller chunks ...
its about 30% on a very small sample ...
(back in town from the weekend, to see the PostgreSQL tarball ripped to
shreds ;)
Peter, I'm with you on this. If folks want to help support PostgreSQL by
providing
I've noticed a pg_dump/pg_dumpall problem with timestamp variables, in
dumping the minute, and second values:
instead of dumping
12:01:00.00 it dumps out 12:60:00.00 which is not accepted when
restoring a database...
You are running the Mandrake distro, or somehow compiling with a bad set
Where can I get a Postscript version docs for 7.1?
I'll start building hardcopy in the next day or two, and hope that it
will be done quickly (more quickly that in previous releases). Will keep
y'all informed on the progress...
- Thomas
---(end of
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 any
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
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:
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
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, but
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)
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
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 changes?
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 standard
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 to use
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.
-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 the
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
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.
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
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
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,
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
Mathijs Brands wrote:
SNIP
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
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
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
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,
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
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
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
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
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 a
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 Ant
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 that
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:
"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 variables.
36 matches
Mail list logo
