Am Mittwoch, 5. Januar 2005 05:38 schrieb Oleg Bartunov:
> Serguei, I have translations (I didn't touch libpq, psql in work,
> other files seems complete) available from
> http://www.sai.msu.su/~megera/oddmuse/
Let me know when you have something finished and ready to commit.
--
Peter Eisentrau
Am Mittwoch, 5. Januar 2005 10:17 schrieb Alin Vaida:
> Unfortunately, I've been pretty busy for the last weeks, but I'll try to
> make an effort, at least now. So, what's the last day for sending
> translation updates?
The release will probably be early next week, so you had better hurry.
--
Pe
Am Dienstag, 4. Januar 2005 19:03 schrieb Jim Buttafuoco:
> ARM platform fails the "point" test see below.
For the 7.4 release we got a report for the ARM platform where all tests
passed:
http://archives.postgresql.org/pgsql-hackers/2003-10/msg01212.php
So either there are various degrees of AR
Ühel kenal päeval (kolmapäev, 22. detsember 2004, 11:34-0500), kirjutas
Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > It seems that this bug is still lurking in libpq:
> > http://search.postgresql.org/pgsql-hackers/2004-09/msg00703.php
>
> > Is anybody working on it, or should I try so
Ühel kenal päeval (esmaspäev, 3. jaanuar 2005, 22:29-0500), kirjutas
Bruce Momjian:
> This item still seems open. Is it a TODO?
Probably. It bit me quite badly when it was discovered.
I'm hoping to get something done&tested by tomorrow evenning the latest.
--
Hannu Krosing <[EMAIL PROTECTED]>
Am Dienstag, 14. Dezember 2004 23:07 schrieb Rémi Zara:
> Here is a port report for NetBSD 2.0 mac68k, with sources of
> postgresql8.0.0rc1.
It seems we have fixed the assembly syntax and the float8 failure, but the
failure in the misc test seems pretty bogus. Has anyone looked into that
furthe
First, we still do not have any test with 8.0 on the following platforms:
HP-UX
IRIX
Tru64 UNIX
SCO OpenServer
Second, we have regressions (vs. 7.4) on the following platforms:
Linux Alpha (buildfarm hare)
Linux ARM (see
http://archives.postgresql.org/pgsql-hackers/2005-01/msg00094.php)
Other
On Thursday 06 Jan 2005 3:52 pm, Peter Eisentraut wrote:
> First, we still do not have any test with 8.0 on the following platforms:
>
> HP-UX
All the 96 tests are passed on RC3. I can rerun the tests with additional
configure flags if required..But I can not install anything new on HP-UX
machin
On Thu, Jan 06, 2005 at 10:18:58AM +0100, Peter Eisentraut wrote:
> Am Dienstag, 4. Januar 2005 19:03 schrieb Jim Buttafuoco:
> > ARM platform fails the "point" test see below.
>
> For the 7.4 release we got a report for the ARM platform where all tests
> passed:
>
> http://archives.postgresql.o
it looks like a sqrt problem that has been fixed with the linux 2.6 kernel
series. I am going to look and see if I
can get a 2.6 kernel to check it out.
since all of the other tests pass, maybe just a note in the read me file.
Jim
-- Original Message ---
From: Peter Eisentra
Marko,
I am using the stock Debian 2.4.27 kernel. Don't know how to change the fp
setup. Do you have any instructions for
me?
Thanks
Jim
-- Original Message ---
From: Marko Kreen
To: Peter Eisentraut <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], pgsql-hackers
Sent: Thu, 6 Ja
On Thu, Jan 06, 2005 at 09:07:14AM -0500, Jim Buttafuoco wrote:
> I am using the stock Debian 2.4.27 kernel. Don't know how to
> change the fp setup. Do you have any instructions for me?
It can be changed by configuring and recompiling kernel.
I checked the kernel-image-2.4.27-arm package from
Marko/All,
I wrote the following test program
#include
#include
#define HYPOT(A, B) sqrt((A) * (A) + (B) * (B))
int main()
{
printf("SQRT Test\n");
long double a;
a = HYPOT(0-10,0-10);
printf("double a = %20.12Lf\n",a);
exit(0);
- Original Message -
From: "Peter Eisentraut" <[EMAIL PROTECTED]>
Sent: January 06, 2005 3:48 AM
> Am Mittwoch, 5. Januar 2005 05:38 schrieb Oleg Bartunov:
> > Serguei, I have translations (I didn't touch libpq, psql in work,
> > other files seems complete) available from
> > http://www.
On Thu, Jan 06, 2005 at 10:18:58AM +0100, Peter Eisentraut wrote:
> For the 7.4 release we got a report for the ARM platform where all tests
> passed:
>
> http://archives.postgresql.org/pgsql-hackers/2003-10/msg01212.php
Additional info point:
> (sid)noel ( at ) debussy:~/postgresql-cvs/pgsql$
Marko,
See my email with test program. I will recompile the kernel and get back to
the list
Jim
-- Original Message ---
From: Marko Kreen
To: Jim Buttafuoco <[EMAIL PROTECTED]>
Cc: Peter Eisentraut <[EMAIL PROTECTED]>, pgsql-hackers
Sent: Thu, 6 Jan 2005 16:58:03 +0200
Sub
On Thu, Jan 06, 2005 at 10:21:43AM -0500, Jim Buttafuoco wrote:
> I will recompile the kernel and get back to the list
Thanks. This way we can be sure it is FP-emulation effect.
--
marko
---(end of broadcast)---
TIP 8: explain analyze is your fr
Hello.
From: Peter Eisentraut <[EMAIL PROTECTED]>
Subject: [HACKERS] Porting/platforms/buildfarm open issues
Date: Thu, 6 Jan 2005 11:22:56 +0100
> Tru64 UNIX
I tried RC3 on Tru64 box with cc(Compaq C V6.1-011). There are some errors
to build and install. All tests (make installcheck) are passed
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Dienstag, 14. Dezember 2004 23:07 schrieb Rémi Zara:
>> Here is a port report for NetBSD 2.0 mac68k, with sources of
>> postgresql8.0.0rc1.
> It seems we have fixed the assembly syntax and the float8 failure, but the
> failure in the misc test see
Shridhar Daithankar <[EMAIL PROTECTED]> writes:
> On Thursday 06 Jan 2005 3:52 pm, Peter Eisentraut wrote:
>> First, we still do not have any test with 8.0 on the following platforms:
>>
>> HP-UX
> All the 96 tests are passed on RC3. I can rerun the tests with additional
> configure flags if req
Marko,
I couldn't get 2.4.27 to patch with the arm patches, so I downloaded 2.4.25
(with has CONFIG_FPE_NWFPE=y) and ALL
tests passed. So I will file a bug report with Debian. We should also put
something in the Postgresql readme about
this issue.
Jim
-- Original Message -
Peter Eisentraut wrote:
Second, we have regressions (vs. 7.4) on the following platforms:
Linux Alpha (buildfarm hare)
This was apparently an old Alpha chip, and Jim was going to try on a
more modern machine not known to have FP problems. So take this result
with many grains of salt.
cheers
On Thu, Jan 06, 2005 at 11:39:14AM -0500, Jim Buttafuoco wrote:
> I couldn't get 2.4.27 to patch with the arm patches, so I downloaded 2.4.25
> (with has CONFIG_FPE_NWFPE=y) and ALL
> tests passed. So I will file a bug report with Debian. We should also put
> something in the Postgresql readme
Marko Kreen wrote:
On Thu, Jan 06, 2005 at 11:39:14AM -0500, Jim Buttafuoco wrote:
I couldn't get 2.4.27 to patch with the arm patches, so I downloaded 2.4.25 (with has CONFIG_FPE_NWFPE=y) and ALL
tests passed. So I will file a bug report with Debian. We should also put something in the Post
On Thu, Jan 06, 2005 at 12:32:12PM -0500, Andrew Dunstan wrote:
> Marko Kreen wrote:
> >The question is rather how to handle it in PostgreSQL
> >regression testing:
> >1) Document the need for NWFPE - which gives standard results.
> >2) Use FastFPE results on Linux/ARM.
> >3) Autodetect - ok, that
Marko Kreen writes:
> I have not looked at pg_regress much and had not noticed the
> 'unconditional alternative' feature. I only thought of the
> resultmap alternative. Unconditionally adding FastFPE results
> may even be good, so that FastFPE can pass on any platform.
No, it would be bad, beca
Tom Lane wrote:
I have noticed an increasing tendency among the buildfarm crew to think
that the regression tests should show zero diffs on all platforms no
matter what. That is not the design goal. The intent is to tell you
about possible problems. If you decide that a particular diff isn't
re
On Thu, Jan 06, 2005 at 02:05:17PM -0500, Tom Lane wrote:
> Marko Kreen writes:
> > I have not looked at pg_regress much and had not noticed the
> > 'unconditional alternative' feature. I only thought of the
> > resultmap alternative. Unconditionally adding FastFPE results
> > may even be good,
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Tom Lane:
>> Go for it. The difficulty I think is testing that the failure path
>> actually does the right thing. Do you have the ability to provoke
>> the failure on demand?
> the easiest way to provoke it is running the following code in a python
> i
Just to keep everyone in the loop at what we are looking at right now.
RC4 - Packaged tonight, Announced Friday AM
Full Release - Packaged Monday Night, PR/Announce Tuesday AM
If *anyone* is sitting on something, plesae let us know ASAP ... I'm
planning on packaging up RC4 tonight around
Honda Shigehiro <[EMAIL PROTECTED]> writes:
> So, I need a patch to build:
> bash-2.05b$ diff Makefile.osf.DIST Makefile.osf
> 4c4
> < rpath = -Wl,-rpath -Wl,$(rpathdir)
> ---
> > rpath = -rpath $(rpathdir)
OK; this simply reverts a cosmetic change I made awhile ago. Evidently
that wasn't a good
>Just to keep everyone in the loop at what we are looking at right now.
>
>RC4 - Packaged tonight, Announced Friday AM
>Full Release - Packaged Monday Night, PR/Announce Tuesday AM
>
>If *anyone* is sitting on something, plesae let us know ASAP ... I'm
>planning on packaging up RC4 tonigh
Just a thought - considering it's just a weekend in between, isn't the
time between RC4 and release a little bit on the shortside? I mean, not
a lot of people will have time to test it "for real" in that time...
While there aren't any large changes, it never hurts to be on the safe
side?
(Remember
Magnus Hagander wrote:
> >Just to keep everyone in the loop at what we are looking at right now.
> >
> >RC4 - Packaged tonight, Announced Friday AM
> >Full Release - Packaged Monday Night, PR/Announce Tuesday AM
> >
> >If *anyone* is sitting on something, plesae let us know ASAP ... I'm
>
I apologize for the significant delay, here's a link to results to a
test with 8.0rc3:
http://www.osdl.org/projects/dbt2dev/results/dev4-010/236/
These are the same parameters with as run 215, listed below with the
but with --enable-debug --enable-cassert. I also ran pg_autovacuum
with -d
Marko Kreen wrote:
The unconditional-acceptance thing has to be used with great caution;
preferably only for issues that we expect on many platforms (such as
locale dependencies).
How about the following then: let pg_regress.sh accept multiple
choices from resultmap.
Good idea. I was think
On Thu, 6 Jan 2005, Bruce Momjian wrote:
Magnus Hagander wrote:
Just to keep everyone in the loop at what we are looking at right now.
RC4 - Packaged tonight, Announced Friday AM
Full Release - Packaged Monday Night, PR/Announce Tuesday AM
If *anyone* is sitting on something, plesae let us
Check her over .. will do a general announce in the morning ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---(end of broadcast)---
TIP
Do we want to add this additional log infor to CVS for 8.0?
---
Simon Riggs wrote:
> On Mon, 2005-01-03 at 19:14 -0500, Bruce Momjian wrote:
> > Simon Riggs wrote:
> > > Here's my bgwriter instrumentation patch, which gives
On Jan 7, 2005, at 4:35, Andrew Dunstan wrote:
The buildfarm is a dashboard application - when everything is OK you
want it to show all green. If that's not a goal, then some redesign is
appropriate. Perhaps buildfarm needs its own test suite, rather than
leveraging those in the distribution, al
I'm the last person to argue against delaying to get it right :) But,
if we are going to delay to end of week, why not just make it a Sun
package, Mon release, so that Josh et al can get the best bang for the
PR/release announcement?
I think that we would then want a tuesday release. It is my
On Jan 7, 2005, at 15:44, Joshua D. Drake wrote:
I'm the last person to argue against delaying to get it right :)
But, if we are going to delay to end of week, why not just make it a
Sun package, Mon release, so that Josh et al can get the best bang
for the PR/release announcement?
I think tha
42 matches
Mail list logo
