Scott you're right, it was a hardware problem.
Thanks for your help.
Nicolas VERGER
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED]] De la part de scott.marlowe
Envoyé : mercredi 6 novembre 2002 21:38
À : Nicolas VERGER
Cc : 'PostgreSQL Hackers
Tom Lane wrote:
Pedro M. Ferreira [EMAIL PROTECTED] writes:
[ patch for extra_float_digits ]
I've applied this patch along with followup changes to pg_dump (it sets
extra_float_digits to 2 to allow accurate dump/reload) and the geometry
regression test (it sets extra_float_digits to -3).
I
On Tue, 12 Nov 2002, Bruce Momjian wrote:
Are we ready for RC1 yet?
This is Tuesday, you can only ask on Fridays :)
Vince.
--
http://www.meanstreamradio.com http://www.unknown-artists.com
Internet radio: It's not file sharing, it's just radio.
Are we ready for RC1 yet?
I'm waiting for jenny wang confirms the fix regarding GB18030
support. In the mean time, I'll commit the fix anyway since current
GB183030 support is so badly broken (I have checked all regression
tests have passed).
--
Tatsuo Ishii
---(end of
Does any know the location of a good cvsup file for grabbing the
various releases?
There is none; when the configuration was changed the docs were not.
Use the appendix in the current docs (not whatever TODO is) and replace
the pgsql project name with repository. Your CVS area will then
tom lane wrote:
What can you do *without* using a raw partition?
I dislike that idea for two reasons: portability and security. The
portability disadvantages are obvious. And in ordinary system setups
Postgres would have to run as root in order to write on a raw partition.
It occurs to me
'K, looks like we need two things confirmed ... the change that Tom made
concerning mktime(), which we need someone on AIX to test ... and the
following ...
I've been following the commit messages closely, and haven't seen anything
go in that make me edgy, so if we can get validation on those
Are we ready for RC1 yet?
I think so. The NO_MKTIME_BEFORE_1970 issue was bothering me, but I
feel that's resolved now. (It'd be nice to hear a crosscheck from
some AIX users though...)
abstime, tinterval and horology fail on AIX.
The rest is now working (AIX 4.3.2 xlc 5.0.0.2).
I am
On Tue, 12 Nov 2002, Nicolas VERGER wrote:
Scott you're right, it was a hardware problem.
Thanks for your help.
Glad to be of help. What was the problem? Bad memory or bad hard drive?
Just curious.
---(end of broadcast)---
TIP 6: Have you
Curtis, have you considered comparing raw writes versus file system writes
on a raw multi-disk partition?
I always set up my machines to store data on a mirror set (RAID1) or RAID5
set, and it seems your method should be tested there too.
P.s., Tom, the postgresql user would NOT need to run
I have removed the NO_MKTIME_BEFORE_1970 symbol from irix5.h,
rebuilt 7.3b2, and reran the regression. The three time tests
(tinterval, horology, abstime) now match the Solaris expected files.
I checked the timezone files, and the system does not appear to
have savings time
if (ic_flag == 1) {
/*only select those non-IC/Spyder nodes that has full update set*/
EXEC SQL DECLARE full_dyn_node CURSOR FOR
SELECT node_name FROM NODE
WHERE dynamic_community = 'f' AND ic_flag='n' AND machine_type!=22
Tatsuo, are you or anyone else working on adding PREPARE, EXECUTE support to
pgbench?
If not, I can do it myself and if you are interested, I'll send you the
patch.
- Curtis
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
Mikheev, Vadim [EMAIL PROTECTED] writes:
Wouldn't it work for cntxDirty to be set not by LockBuffer, but by
XLogInsert for each buffer that is included in its argument list?
I thought to add separate call to mark context dirty but above
should work if all callers to XLogInsert always pass all
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
abstime, tinterval and horology fail on AIX.=20
I would expect them now (without NO_MKTIME_BEFORE_1970) to match the
solaris-1947 comparison files for these tests. Could you confirm that?
regards, tom lane
I think so. The NO_MKTIME_BEFORE_1970 issue was bothering me, but I
feel that's resolved now. (It'd be nice to hear a crosscheck from
some AIX users though...)
abstime, tinterval and horology fail on AIX.
The rest is now working (AIX 4.3.2 xlc 5.0.0.2).
I am just now rebuilding
hi,
i think that ecpg is only text preprocessor. it doesn't understand the c
semantics - it goes from the top to the end of the file row by row and
sees your declaration twice.
kuba
On Tue, 12 Nov 2002, Marc G. Fournier wrote:
if (ic_flag == 1) {
/*only select those
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
Ok, when #define NO_MKTIME_BEFORE_1970 is removed from aix.h, then the
results match the Solaris files.
Great!
Attached is a patch to make AIX match Solaris. Please apply and add AIX
to the supported platforms.
Patch applied to 7.3 and CVS
I have been doing some research about how to create new routines for
string collation and character case mapping that would allow us to break
out of the one-locale-per-process scheme. I have found that the Unicode
standard provides a lot of useful specifications and data for this. The
Unicode
Tom Lane wrote:
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
Ok, when #define NO_MKTIME_BEFORE_1970 is removed from aix.h, then the
results match the Solaris files.
Great!
Attached is a patch to make AIX match Solaris. Please apply and add AIX
to the supported platforms.
Tatsuo, are you or anyone else working on adding PREPARE, EXECUTE support to
pgbench?
As far as I know, no one is working on that.
If not, I can do it myself and if you are interested, I'll send you the
patch.
Thanks. I can commit it for 7.4. BTW, it would be nice if we could
have a switch
Bruce Momjian writes:
Are we ready for RC1 yet?
Questionable. We don't even have 50% confirmation coverage for the
supported platforms yet.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading through
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian writes:
Are we ready for RC1 yet?
Questionable. We don't even have 50% confirmation coverage for the
supported platforms yet.
We can't just wait around indefinitely for port reports that may or may
not ever appear. In any case, most
On Tue, 2002-11-12 at 16:27, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian writes:
Are we ready for RC1 yet?
Questionable. We don't even have 50% confirmation coverage for the
supported platforms yet.
We can't just wait around indefinitely for port reports
On 12 Nov 2002, Robert Treat wrote:
On Tue, 2002-11-12 at 16:27, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian writes:
Are we ready for RC1 yet?
Questionable. We don't even have 50% confirmation coverage for the
supported platforms yet.
We can't
On 12 Nov 2002, Robert Treat wrote:
On Tue, 2002-11-12 at 16:27, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Bruce Momjian writes:
Are we ready for RC1 yet?
Questionable. We don't even have 50% confirmation coverage for the
supported platforms yet.
We can't
scott.marlowe [EMAIL PROTECTED] writes:
And then it stops. Anyone know why it doesn't run the rest of the
regresssion tests?
Somebody else just reported the same thing on Solaris. Must be
something about the pg_regress script that doesn't play nicely with
Solaris' shell. Can you poke into
On Tue, 12 Nov 2002, Tom Lane wrote:
scott.marlowe [EMAIL PROTECTED] writes:
And then it stops. Anyone know why it doesn't run the rest of the
regresssion tests?
Somebody else just reported the same thing on Solaris. Must be
something about the pg_regress script that doesn't play
On Tue, 12 Nov 2002, Tom Lane wrote:
scott.marlowe [EMAIL PROTECTED] writes:
And then it stops. Anyone know why it doesn't run the rest of the
regresssion tests?
Somebody else just reported the same thing on Solaris. Must be
something about the pg_regress script that doesn't play
scott.marlowe [EMAIL PROTECTED] writes:
OK, make -x check fails, is there some other way to use -x I'm not
thinking of here?
I was thinking of running the script by hand, not via make:
/bin/sh -x ./pg_regress --temp-install --top-builddir=../../..
--schedule=./parallel_schedule
On Tue, 12 Nov 2002, Tom Lane wrote:
scott.marlowe [EMAIL PROTECTED] writes:
OK, make -x check fails, is there some other way to use -x I'm not
thinking of here?
I was thinking of running the script by hand, not via make:
/bin/sh -x ./pg_regress --temp-install --top-builddir=../../..
scott.marlowe [EMAIL PROTECTED] writes:
Ok, now that I've run it that way, the last couple of pages of output
look like this:
Hm. So the while read line loop is iterating only once.
I was thinking to myself that something within the while loop must be
eating up stdin, so that there's nothing
Tatsuo Ishii wrote:
Tatsuo, are you or anyone else working on adding PREPARE, EXECUTE support to
pgbench?
As far as I know, no one is working on that.
If not, I can do it myself and if you are interested, I'll send you the
patch.
Thanks. I can commit it for 7.4. BTW, it would be
Bravo Curtis,
This is all excellent research.
:-)
Regards and best wishes,
Justin Clift
Curtis Faith wrote:
snip
Disk space is much cheaper than CPU and memory so I think that a logging
system that used as much as three or four times the space but is three or
four times faster would be a
Tom Lane wrote:
Thomas Lockhart [EMAIL PROTECTED] writes:
What would be required to have OIDs for all SELECT/INTO product tables
for this release?
It *might* work to just reverse the default assumption in
ExecAssignResultTypeFromTL(). But I will vote against making such a
change at
Thanks. I can commit it for 7.4. BTW, it would be nice if we could
have a switch to turn on/off PREPARE/EXECUTE in pgbench so that we
could see how PRPARE/EXECUTE could improve the performance...
We could probably just run before-after patch tests to see the
performance change. I am
Tatsuo Ishii wrote:
Thanks. I can commit it for 7.4. BTW, it would be nice if we could
have a switch to turn on/off PREPARE/EXECUTE in pgbench so that we
could see how PRPARE/EXECUTE could improve the performance...
We could probably just run before-after patch tests to see the
Tatsuo Ishii [EMAIL PROTECTED] writes:
Thanks. I can commit it for 7.4. BTW, it would be nice if we could
have a switch to turn on/off PREPARE/EXECUTE in pgbench so that we
could see how PRPARE/EXECUTE could improve the performance...
That is a *must*. Otherwise, you've simply made an
Hi,
Has anyone given much thought to improving pg_dump's object order algorithm
for 7.4? It seems that now we have dependencies, it should just be a matter
of doing a breadth-first or depth-first search over the pg_depend table to
generate a valid order of oids.
To allow for mess-ups in that
At 01:33 PM 13/11/2002 +0800, Christopher Kings-Lynne wrote:
Does this sound like an idea?
It does, but in keeping with allowing pg_restore to be quite flexible, I'd
like to see the dependency data stored in the dump file, then processed at
restore-time.
I've just become rather frustrated
pg_dump already has rudimentary dependency tracking (one level
deep); each
item can have a list of oid's it depends on. You *could* patch it to add
the types to the table dependencies.
In the future I'd imagine we'll just dump the OIDs of all first level
dependencies for each object, then
But one of the purposes of pgbench is examining performance on
different environments, doesn't it? I'm afraid hard coded
PREPARE/EXECUTE makes it harder.
I was just thinking that pgbench is for measuring code changes, not for
testing changes _in_ pgbench. Once we know the performance
Tatsuo Ishii wrote:
But one of the purposes of pgbench is examining performance on
different environments, doesn't it? I'm afraid hard coded
PREPARE/EXECUTE makes it harder.
I was just thinking that pgbench is for measuring code changes, not for
testing changes _in_ pgbench. Once
Hey Hackers -
I was testing beta5 and found a performance regression involving
application of constraints into a VIEW - I've got a view that is fairly
expensive, involving a subselet and an aggregate. When the query is
rewritten in 7.2.3, the toplevel constraint is used to filter before
the
My concern is PREPARE/EXECUTE may NOT always improve the
performance. I guess we have very few data to judge PREPARE/EXECUTE is
good or not. Moreover PREPARE/EXECUTE might be improved in the
future. If that happens, keeping that switch would help examining the
effect, no?
It would. I
Ross J. Reedstrom wrote:
Hey Hackers -
I was testing beta5 and found a performance regression involving
application of constraints into a VIEW - I've got a view that is fairly
expensive, involving a subselet and an aggregate. When the query is
rewritten in 7.2.3, the toplevel constraint is used
Paul,
Unable to identify an operator '=' for types 'numeric' and 'double
precision' You will have to retype this query using an explicit cast
This is due, as you surmised, to decimal values defaulting to floats.
While there is little problem with an = operator for numeric and
float, you would
Josh Berkus [EMAIL PROTECTED] writes:
Now, that's interesting. Why would defining a numeric = float have
broken numeric = integer? There's no reason I can think of.
The problem probably is that the parser now finds two possible
interpretations that look equally good to it, so it can't
48 matches
Mail list logo
