I thought I'd throw SPARC into the equation (SPARC IIIi, in a dual SunFire
v250):
vanilla HEAD from ~1 week ago:
bash-3.00$ for i in 1 2 4; do time ./nrun.sh $i; done
real1m49.037s
user0m0.008s
sys 0m0.016s
real2m3.482s
user0m0.014s
sys 0m0.026s
real3m54.215s
user
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Conway
Sent: 16 September 2005 03:48
To: Tom Lane
Cc: Marc G. Fournier; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Beta2 Wrap Up ...
On Thu, 2005-15-09 at 22:31 -0400, Tom Lane
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Neil Conway
Sent: 16 September 2005 06:38
To: Marc G. Fournier
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Beta2 Wrap Up ...
On Thu, 2005-15-09 at 22:06 -0400, Neil Conway wrote:
Hi,
After / before 8.1 Beta 2, are there any plans to release new dot releases
for the back branches?
Regards,
--
Devrim GUNDUZ
Kivi Bilişim Teknolojileri - http://www.kivi.com.tr
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org
With there be a win32 version of beta2? or a beta1?
Thanks,
Tony
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
This has been saved for the 8.2 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Patrick Welche wrote:
Ilya Kovalenko posted some code at in a thread starting at
Hello
I am testing comformity between PostgreSQL and Oracle. I found one
difference. Century started 1900-01-01 for Oracle and 1901-01-01 for
PostgreSQL. What value is good?
Best regards
Pavel Stehule
_
Chcete sdilet sve
Tony Caduto napsal(a):
With there be a win32 version of beta2? or a beta1?
ftp://ftp.postgresql.org/pub/binary/v8.1beta/win32/
(join -hackers-win32 if you want to be informed about win32 specific stuff)
--
Regards
Petr Jelinek (PJMODOS)
www.parba.cz
---(end of
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tony Caduto
Sent: 16 September 2005 11:19
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] 8.1 win32 beta?
With there be a win32 version of beta2? or a beta1?
There will be a beta2. There was
It occurs to me that there is no longer any great need to have a
separate hackers list for win32 development. Perhaps we should close it
down now and keep all development on -hackers?
Regards, Dave.
---(end of broadcast)---
TIP 5: don't forget to
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Oliver Jowett wrote:
Simon Riggs wrote:
Are we sure there is just 3 cases?
I haven't exhaustively checked, but I think those are the main cases.
Even if case (3) is not that common, I still want to know it is
occurring, to see what effect or overhead it has.
I don't want it to be
Bruce Momjian wrote:
We don't have a log_statement = verbose mode.
Please see my earlier email where I suggested adding one if you really
wanted all this protocol-level detail logged.
-O
---(end of broadcast)---
TIP 1: if posting/reading
Bruce Momjian wrote:
I think it is more verbose because no FETCH is logged in this type of
prepare/execute. The goal, I think, is for these type of queries to
look as similar to normal PREPARE/EXECUTE and DECLARE/FETCH as possible.
I do not understand why this is a useful thing to do as part
Pavel Stehule wrote:
Hello
I am testing comformity between PostgreSQL and Oracle. I found one
difference. Century started 1900-01-01 for Oracle and 1901-01-01 for
PostgreSQL. What value is good?
Hello,
I think that 1901 is the correct year.
( The first century started in year 1 and ended
Title: Message
Hi,
I have a query on sql_numeric
datatype Can you please clarify on this?
While inserting numeric data type into a
table can you please let me know how you are storing the value in the
database.
Whether it is stored as double or character or
directly storing it as
Dave Page wrote:
[mailto:[EMAIL PROTECTED] On Behalf Of Tony Caduto
With there be a win32 version of beta2? or a beta1?
There will be a beta2. There was no beta1 because it didn't compile on
Windows due to an issue with ipv6, however there is already a post-beta1
release available at
On Fri, 2005-16-09 at 08:47 +0100, Dave Page wrote:
Perhaps you could allow 24 hours before committing potentially
controversial changes in future?
My apologies for the rush -- I normally would wait longer for a
consensus. In fact, I _was_ waiting for a consensus until I saw that the
wrap for
-Original Message-
From: Neil Conway [mailto:[EMAIL PROTECTED]
Sent: 16 September 2005 14:57
To: Dave Page
Cc: Marc G. Fournier; pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] Beta2 Wrap Up ...
On Fri, 2005-16-09 at 08:47 +0100, Dave Page wrote:
Perhaps you could allow
Devrim Gunduz [EMAIL PROTECTED] writes:
After / before 8.1 Beta 2, are there any plans to release new dot releases
for the back branches?
Some day ;-)
What's holding up the back branches at the moment is that the gerbil
buildfarm member is showing failures in the 8.0 branch that started
right
Raghavendra Reddy [EMAIL PROTECTED] writes:
While inserting numeric data type into a table can you please let me
know how you are storing the value in the database.
From src/include/utils/numeric.h:
/*
* The Numeric data type stored in the database
*
* NOTE: by convention, values in
Am Donnerstag, 15. September 2005 05:04 schrieb Tom Lane:
I'm not sure that inverse OR distributive law is standard terminology,
but I believe the implication in the other direction is usually called
the OR distributive law. Anyone know of better terminology?
It's still the OR distributive
What's holding up the back branches at the moment is that the gerbil
buildfarm member is showing failures in the 8.0 branch that started
right after I patched the vacuum/ctid-chain stuff. That probably
indicates a problem, but the owner of the machine has been completely
unhelpful about
Oliver Jowett wrote:
Bruce Momjian wrote:
We don't have a log_statement = verbose mode.
Please see my earlier email where I suggested adding one if you really
wanted all this protocol-level detail logged.
We can't add that in feature freeze/beta, at least.
--
Bruce Momjian
On Fri, Sep 16, 2005 at 06:36:56AM -0400, Bruce Momjian wrote:
This has been saved for the 8.2 release:
It isn't actually a patch for application yet ;-) It is the function in
a state that is easy to test. I take it that as I have basically had
no comments back, I will just go ahead and make a
Oliver Jowett wrote:
Bruce Momjian wrote:
I think it is more verbose because no FETCH is logged in this type of
prepare/execute. The goal, I think, is for these type of queries to
look as similar to normal PREPARE/EXECUTE and DECLARE/FETCH as possible.
I do not understand why this is
On Fri, Sep 16, 2005 at 07:57:08AM -0700, Joshua D. Drake wrote:
What's holding up the back branches at the moment is that the gerbil
buildfarm member is showing failures in the 8.0 branch that started
right after I patched the vacuum/ctid-chain stuff. That probably
indicates a problem, but
Darcy Buskermolen wrote:
On Thursday 04 August 2005 09:37, Gavin M. Roy wrote:
You can send it to me, and ehpg will host it. I'll send you a
private email with my info.
Gavin
On Aug 4, 2005, at 8:26 AM, Mark Woodward wrote:
It is 4.4G in space in a gzip package.
I'll mail a DVD to two
Hackers,
I'm reading the vacuum code and I just noticed that the routines
move_plain_tuple and move_chain_tuple expect the dest and source blocks
to be locked, and unlock them at exit. The only caller of both is
repair_frag, whose only caller in turn is full_vacuum_rel. Same thing
for
Tom,
What I think this means is that the kernel is scheduling the 2 processes
onto 2 processors chosen-at-random, without awareness of whether those
two processors are on the same chip (in the Xeon case) or have closer
NUMA affinity (in the Opteron case).
That would be consistent with my
This is now in the TODO list:
* Merge xmin/xmax/cmin/cmax back into three header fields
Before subtransactions, there used to be only three fields needed to
store these four values. This was possible because only the current
transaction looks at the cmin/cmax values. If the current
Patrick Welche wrote:
On Fri, Sep 16, 2005 at 06:36:56AM -0400, Bruce Momjian wrote:
This has been saved for the 8.2 release:
It isn't actually a patch for application yet ;-) It is the function in
a state that is easy to test. I take it that as I have basically had
no comments back, I
Added to TODO:
* Update Bonjour to work with newer cross-platform SDK
---
Sandy McArthur wrote:
FYI: The DNSServiceDiscovery.h is Mac OS X specific and only kept
around for Mac OS X 10.2 and older
On Fri, Sep 16, 2005 at 09:28:39AM -0600, Michael Fuhr wrote:
FWIW, I have a Solaris 9/sparc box with gcc 3.4.2 (same setup as
gerbil) and have no problems with REL7_2_STABLE through HEAD. I'll
test REL8_0_STABLE with gerbil's configure options when I get a
chance.
I just built REL8_0_STABLE
'k, beta2 is bundled and available on the main ftp server ... will
propogate over the next little while to the various mirrors ... the
announcement for this will go out late Sun/early Mon, to give Dave a
chance to get the Windows Installer built and available at the same time
...
I'm going
Pavel Stehule [EMAIL PROTECTED] writes:
Hello
I am testing comformity between PostgreSQL and Oracle. I found one difference.
Century started 1900-01-01 for Oracle and 1901-01-01 for PostgreSQL. What
value
is good?
out of curiosity, what was your actual test?
--
greg
Josh Berkus josh@agliodbs.com writes:
Tom,
What I think this means is that the kernel is scheduling the 2 processes
onto 2 processors chosen-at-random, without awareness of whether those
two processors are on the same chip (in the Xeon case) or have closer
NUMA affinity (in the Opteron
Simon Riggs wrote:
Currently, when we set a statement_timeout and a query runs over that
time there is no log message to say that the statement has timed out. We
do get a message which says
ERROR: canceling query due to user request
and so in the server log it is impossible to tell
* Greg Stark ([EMAIL PROTECTED]) wrote:
However I was under the impression that 2.6 had moved beyond that problem.
It would be very interesting to know if 2.6 still suffers from this.
The tests on the em64t at my place were using 2.6.12. I had thought 2.6
was better about this too, but I don't
pgman wrote:
Simon Riggs wrote:
Currently, when we set a statement_timeout and a query runs over that
time there is no log message to say that the statement has timed out. We
do get a message which says
ERROR: canceling query due to user request
and so in the server log it is
Was it relcache related?On 9/16/05, Alvaro Herrera [EMAIL PROTECTED] wrote:
Hackers,I'm reading the vacuum code and I just noticed that the routinesmove_plain_tuple and move_chain_tuple expect the dest and source blocksto be locked, and unlock them at exit.The only caller of both is
repair_frag,
On Fri, Sep 16, 2005 at 03:41:11PM -0400, Bruce Momjian wrote:
pgman wrote:
I have updated the message to:
errmsg(canceling query due to user request or statement timeout)));
Oops. Did we freeze the message strings already for this release?
Not yet.
I'm not sure I agree with
On Fri, Sep 16, 2005 at 04:41:39PM -0400, Jonah H. Harris wrote:
Was it relcache related?
I don't see how -- any user of a relcache entry needs to heap_open() or
relation_open() the table and acquire an appropiate lock. Any such call
would block because of the lock that VACUUM FULL acquires on
Bruce Momjian wrote:
Well, from the application writer perspective, you are right it doesn't
make sense,
This is exactly what the end user is going to say.
but this is only because jdbc is using prepare internally.
Isn't this mostly irrelevant to the result we want to see? It's a detail
of
I'm probably wrong, but I thought vacuum may invalidate stuff which
semi-required the cache to be flushed. :) I'll go take a
look through as-well but it's hard to imagine this being overlooked for
so long.
Sorry Alvaro, I haven't gone out to look at vacuum in awhile so I ain't much help.
On
Alvaro Herrera wrote
The only caller of both is
repair_frag, whose only caller in turn is full_vacuum_rel.
...bgwriter still needs to access blocks. The WAL system relies on the
locking behaviour for recoverability, see comments in LockBuffer() and
SyncOneBuffer().
...I do think there's lots
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
I don't see why printing the query cancel from a timeout is any more
special than a user request for cancel or a simple query error. If
users want statements to be printed on error, they will
configure things
that way, if not, we should not
Alvaro Herrera
On Fri, Sep 16, 2005 at 03:41:11PM -0400, Bruce Momjian wrote:
I have updated the message to:
errmsg(canceling query due to user request or
statement timeout)));
Oops. Did we freeze the message strings already for this release?
Not yet.
I'm not sure I agree
Simon Riggs wrote:
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
I don't see why printing the query cancel from a timeout is any more
special than a user request for cancel or a simple query error. If
users want statements to be printed on error, they will
configure things
that way,
Can we remove the BEOS-specific code? I don't think anyone has reported
it working for quite a few releases. If someone wants to take it up
later, they can pull from the CVS commit that removed it.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us
Simon Riggs wrote:
Alvaro Herrera
On Fri, Sep 16, 2005 at 03:41:11PM -0400, Bruce Momjian wrote:
I have updated the message to:
errmsg(canceling query due to user request or
statement timeout)));
Oops. Did we freeze the message strings already for this release?
Not
Stephen Frost [EMAIL PROTECTED] writes:
* Greg Stark ([EMAIL PROTECTED]) wrote:
However I was under the impression that 2.6 had moved beyond that problem.
It would be very interesting to know if 2.6 still suffers from this.
The tests on the em64t at my place were using 2.6.12. I had thought
On Sat, 17 Sep 2005, Tom Lane wrote:
Stephen Frost [EMAIL PROTECTED] writes:
* Greg Stark ([EMAIL PROTECTED]) wrote:
However I was under the impression that 2.6 had moved beyond that problem.
It would be very interesting to know if 2.6 still suffers from this.
The tests on the em64t at
Alvaro Herrera [EMAIL PROTECTED] writes:
So, the only callers of both has already acquired appropiate locks at
the relation level -- nobody is going to be modifying the blocks while
they proceed. So why bother locking the pages at all? Is there a
reason or is this an historical accident?
Gavin Sherry [EMAIL PROTECTED] writes:
On Sat, 17 Sep 2005, Tom Lane wrote:
It'd be real interesting to see comparable numbers from some non-Linux
kernels, particularly commercial systems like Solaris.
Did you see the Solaris results I posted?
Are you speaking of
Bruce Momjian pgman@candle.pha.pa.us writes:
Can we remove the BEOS-specific code? I don't think anyone has reported
it working for quite a few releases. If someone wants to take it up
later, they can pull from the CVS commit that removed it.
I think pulling it during beta is inappropriate:
56 matches
Mail list logo