Re: [pgsql-ru-general] [HACKERS] Final call for translation updates
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 Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [HACKERS] Final call for translation updates
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. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CSV arm check failure
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 ARM processors or something is broken. Ideas? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] oldish libpq bug still in RC2
Ü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 something myself, perhaps just replacing the lone recv() with pqsecure_read() ? 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 interpreter ---888888-- import socket HOST = '' PORT = def close_on_connect_server(): s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind((HOST, PORT)) s.listen(1) conn, addr = s.accept() print 'Connected by', addr conn.close() close_on_connect_server() ---888888-- and then connect to it with psql $ psql -h 127.0.0.1 -p anydb this causes the python function to terminate and psql will start using all available CPU in tight recv() loop. I'm not sure I will get around to fixing it very soon , though I hoped I can. -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] oldish libpq bug still in RC2
Ü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 donetested by tomorrow evenning the latest. -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Port report: NetBSD 2.0 mac68k
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 further? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Porting/platforms/buildfarm open issues
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 open targets can be found here: http://developer.postgresql.org/docs/postgres/supported-platforms.html but those were the most important ones. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Porting/platforms/buildfarm open issues
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 machine. $ ./configure --without-readline --without-zlib;gmake;gmake check $ uname -a HP-UX machine B.11.00 A 9000/785 2005950738 two-user license FWIW, I also ran on my Linux machine. It passes there as well.. $ ./configure;make;make check $ uname -a Linux machine 2.6.7 #1 Wed Jun 16 16:23:03 PDT 2004 i686 unknown unknown GNU/Linux $ cat /etc/slackware-version Slackware 10.0.0 Shridhar ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] CSV arm check failure
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.org/pgsql-hackers/2003-10/msg01212.php So either there are various degrees of ARM processors or something is broken. Ideas? Yes, there are various degrees of those, but most of them should be FPU-less. So FPU-emulation details would be interesting. In case of Linux there are 3 variants: NWFPE: default FastFPE: only 32-bit mantissa, 4-8x faster than NWFPE gcc -msoft-float: no FP instructions, direct calls. This changes calling convention, so requires that all code is compiled with this. Jim, do you happen to use FastFPE? -- marko ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] CSV arm check failure
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 Eisentraut [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: pgsql-hackers pgsql-hackers@postgresql.org Sent: Thu, 6 Jan 2005 10:18:58 +0100 Subject: Re: [HACKERS] CSV arm check failure 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 ARM processors or something is broken. Ideas? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org --- End of Original Message --- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CSV arm check failure
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 marko@l-t.ee To: Peter Eisentraut [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], pgsql-hackers pgsql-hackers@postgresql.org Sent: Thu, 6 Jan 2005 15:26:05 +0200 Subject: Re: [HACKERS] CSV arm check failure 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.org/pgsql-hackers/2003-10/msg01212.php So either there are various degrees of ARM processors or something is broken. Ideas? Yes, there are various degrees of those, but most of them should be FPU-less. So FPU-emulation details would be interesting. In case of Linux there are 3 variants: NWFPE: default FastFPE: only 32-bit mantissa, 4-8x faster than NWFPE gcc -msoft-float: no FP instructions, direct calls. This changes calling convention, so requires that all code is compiled with this. Jim, do you happen to use FastFPE? -- marko ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match --- End of Original Message --- ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] CSV arm check failure
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 Debian/testing and indeed it uses FastFPE emulation. To be specific, the 'bast' and 'netwinder' targets do. The 'lart', 'riscpc' and 'riscstation' targets use NWFPE. I guess 'lart' and 'bast' are some devel boards and 'netwinder' is the main target. Looking at handhelds.org kernels they mostly use NWFPE although there are couple of configs with FastFPE. I have no clue on other Linux distros or *BSD's on ARM. It seems PostgreSQL may encounter both NWFPE and FastFPE on Linux/ARM. How to handle this I do not know. -- marko ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] CSV arm check failure
Marko/All,
I wrote the following test program
#include stdio.h
#include math.h
#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);
}
and compiled it as follows
gcc -lm -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels
-fno-strict-aliasing -g -o sqrttest sqrt.c
with the following results:
SQRT Test
double a = 14.142135623731
which is the exact answer in the results file for point.
Now if I use perl instead of C I get the wrong answer 14.1421356237309 which
is what postgres is also reporting. So
this looks like a compile time problem which is alittle over my head.
Any idea's
Jim
Jim
-- Original Message ---
From: Marko Kreen marko@l-t.ee
To: Peter Eisentraut [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], pgsql-hackers pgsql-hackers@postgresql.org
Sent: Thu, 6 Jan 2005 15:26:05 +0200
Subject: Re: [HACKERS] CSV arm check failure
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.org/pgsql-hackers/2003-10/msg01212.php
So either there are various degrees of ARM processors or something is
broken.
Ideas?
Yes, there are various degrees of those, but most of them should be
FPU-less. So FPU-emulation details would be interesting.
In case of Linux there are 3 variants:
NWFPE: default
FastFPE: only 32-bit mantissa, 4-8x faster than NWFPE
gcc -msoft-float: no FP instructions, direct calls. This
changes calling convention, so requires that all
code is compiled with this.
Jim, do you happen to use FastFPE?
--
marko
--- End of Original Message ---
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [pgsql-ru-general] [HACKERS] Final call for translation updates
- 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.sai.msu.su/~megera/oddmuse/ Let me know when you have something finished and ready to commit. Will be in soon. -s ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] CSV arm check failure
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$ uname -a Linux debussy 2.4.19-netwinder #1 Thu Mar 20 03:14:34 CET 2003 armv4l GNU/Linux I am guessing: the distro was Debian. I cant find 2.4.19-netwinder kernel but 2.4.16-netwinder from Debian/stable uses NWFPE. o Debian has changed from NWFPE to FastFPE at some point in time. -- marko ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] CSV arm check failure
Marko, See my email with test program. I will recompile the kernel and get back to the list Jim -- Original Message --- From: Marko Kreen marko@l-t.ee To: Jim Buttafuoco [EMAIL PROTECTED] Cc: Peter Eisentraut [EMAIL PROTECTED], pgsql-hackers pgsql-hackers@postgresql.org Sent: Thu, 6 Jan 2005 16:58:03 +0200 Subject: Re: [HACKERS] CSV arm check failure 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 Debian/testing and indeed it uses FastFPE emulation. To be specific, the 'bast' and 'netwinder' targets do. The 'lart', 'riscpc' and 'riscstation' targets use NWFPE. I guess 'lart' and 'bast' are some devel boards and 'netwinder' is the main target. Looking at handhelds.org kernels they mostly use NWFPE although there are couple of configs with FastFPE. I have no clue on other Linux distros or *BSD's on ARM. It seems PostgreSQL may encounter both NWFPE and FastFPE on Linux/ARM. How to handle this I do not know. -- marko --- End of Original Message --- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] CSV arm check failure
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 friend
Re: [HACKERS] Porting/platforms/buildfarm open issues
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. bash-2.05b$ uname -a OSF1 kiss.my.domain V5.0 910 alpha bash-2.05b$ make installcheck ... == All 96 tests passed. == Error Reports: (Sorry for my poor English.) 1) configure? I got below error when simply configure and make: /usr/bin/ld -shared -expect_unresolved '*' fe-auth.o fe-connect.o fe-exec.o fe-misc.o fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o pqsignal.o fe-secure.o md5.o ip.o wchar.o encnames.o noblock.o pgstrcasecmp.o thread.o getaddrinfo.o -L../../../src/port -lresolv -Wl,-rpath -Wl,/usr/local/pgsql/lib -o libpq.so.3.2 /usr/bin/ld: Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4 /usr/bin/ld: Usage: /usr/bin/ld [options] file [...] make[3]: *** [libpq.so.3.2] Error 1 In Makefile.osf, rpath are defined as 'rpath = -Wl,-rpath -Wl,$(rpathdir)'. But, Makefile.global were set LD to /usr/bin/ld by configure script: bash-2.05b$ grep LD Makefile.global LD = /usr/bin/ld 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) (Because LDREL=-r is fixed in Makefile.global.in and cc command can not pass -r flag to linker, I did not set LD environment vriable to /usr/bin/cc.) I believe that it will be no problem if I had used gcc. 2) mkdir? Due to odd behavior of 'mkdir -p' command, I got below error when 'make install': mkdir -p -- /usr/local/pgsql/bin /usr/local/pgsql/share mkdir: cannot create /usr/local/pgsql/share. /usr/local/pgsql/share: File exists make[2]: *** [installdirs] Error 2 So, i needed patches below: bash-2.05b$ diff include/Makefile.DIST include/Makefile 21c21 nodes optimizer parser port regex rewrite storage tcop utils \ --- nodes optimizer parser regex rewrite storage tcop utils \ (port directory were specified twice.) bash-2.05b$ diff backend/Makefile.DIST backend/Makefile 184c184 $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(datadir) --- $(mkinstalldirs) $(DESTDIR)$(datadir) $(DESTDIR)$(bindir) (The mkdir command(of OS standard) fail if there are no-existing directory in middle of paths of the argument. For example, bash-2.05b$ mkdir abc --- success. bash-2.05b$ mkdir -p abc abc2 --- success. the last 'abc2' don't exist. bash-2.05b$ mkdir -p abc3 abc abc2 --- failure. the first 'abc3' don't exist mkdir: cannot create abc. abc: File exists bash-2.05b$ mkdir -p abc5 abc5 --- failuer. both of 'abc5' don't exist mkdir: cannot create abc5. abc5: File exists ) regards, -- Shigehiro Honda ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Port report: NetBSD 2.0 mac68k
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 seems pretty bogus. Has anyone looked into that further? We fixed it: http://archives.postgresql.org/pgsql-committers/2004-12/msg00341.php There is still a contrib check failure on that platform, but we concluded that it represented a compiler bug. I think we can call the platform supported anyway. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Porting/platforms/buildfarm open issues
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 required..But I can not install anything new on HP-UX machine. $ ./configure --without-readline --without-zlib;gmake;gmake check $ uname -a HP-UX machine B.11.00 A 9000/785 2005950738 two-user license I can assure you it works on 10.20 as well ;-) $ uname -a HP-UX sss2 B.10.20 C 9000/780 2004473515 32-user license I have done port testing using both gcc and vendor's cc on HPUX 11.11 (PA-RISC) and 11.23 (Itanium) at HP's testdrive farm. The last time was a month or two back, so it's possible that something broke since then, but it seems highly unlikely. It's also been a month or two since I last tried vendor's cc on 10.20, but I doubt that broke either. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] CSV arm check failure
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 --- From: Marko Kreen marko@l-t.ee To: Jim Buttafuoco [EMAIL PROTECTED] Cc: Peter Eisentraut [EMAIL PROTECTED], pgsql-hackers pgsql-hackers@postgresql.org Sent: Thu, 6 Jan 2005 17:25:20 +0200 Subject: Re: [HACKERS] CSV arm check failure 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 friend --- End of Original Message --- ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Porting/platforms/buildfarm open issues
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 andrew ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] CSV arm check failure
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 about this issue. I do not think its bug in Debian or kernel - it is expected and documented behaviour of FastFPE to have less precision. Also if you think of ARM usage scenarious it seems fine to use lighter emulation. 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 was a joke. I guess 1) is fine now. 2) should be done when FastFPE is standard on Linux/ARM. -- marko ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CSV arm check failure
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 Postgresql readme about this issue. I do not think its bug in Debian or kernel - it is expected and documented behaviour of FastFPE to have less precision. Also if you think of ARM usage scenarious it seems fine to use lighter emulation. 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 was a joke. I guess 1) is fine now. 2) should be done when FastFPE is standard on Linux/ARM. Why not just add an alternative regression output? pg_regress is designed to handle it, and we have quite a few of those already to deal with minor FP differences. Reminder: here is the complete set of diffs: *** ./expected/point.outTue Jan 4 10:55:16 2005 --- ./results/point.out Tue Jan 4 12:40:50 2005 *** *** 101,107 | (-3,4) |5 | (-10,0)| 10 | (-5,-12) | 13 ! | (10,10)| 14.142135623731 | (5.1,34.5) | 34.8749193547455 (6 rows) --- 101,107 | (-3,4) |5 | (-10,0)| 10 | (-5,-12) | 13 ! | (10,10)| 14.1421356237309 | (5.1,34.5) | 34.8749193547455 (6 rows) *** *** 127,134 | (-5,-12) | (-10,0)| 13 | (-5,-12) | (0,0) | 13 | (0,0) | (-5,-12) | 13 !| (0,0) | (10,10)| 14.142135623731 !| (10,10)| (0,0) | 14.142135623731 | (-3,4) | (10,10)| 14.3178210632764 | (10,10)| (-3,4) | 14.3178210632764 | (-5,-12) | (-3,4) | 16.1245154965971 --- 127,134 | (-5,-12) | (-10,0)| 13 | (-5,-12) | (0,0) | 13 | (0,0) | (-5,-12) | 13 !| (0,0) | (10,10)| 14.1421356237309 !| (10,10)| (0,0) | 14.1421356237309 | (-3,4) | (10,10)| 14.3178210632764 | (10,10)| (-3,4) | 14.3178210632764 | (-5,-12) | (-3,4) | 16.1245154965971 *** *** 198,204 | (-10,0)| (0,0) | 10 | (-10,0)| (-5,-12) | 13 | (-5,-12) | (0,0) | 13 ! | (0,0) | (10,10)| 14.142135623731 | (-3,4) | (10,10)| 14.3178210632764 | (-5,-12) | (-3,4) | 16.1245154965971 | (-10,0)| (10,10)| 22.3606797749979 --- 198,204 | (-10,0)| (0,0) | 10 | (-10,0)| (-5,-12) | 13 | (-5,-12) | (0,0) | 13 ! | (0,0) | (10,10)| 14.1421356237309 | (-3,4) | (10,10)| 14.3178210632764 | (-5,-12) | (-3,4) | 16.1245154965971 | (-10,0)| (10,10)| 22.3606797749979 cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CSV arm check failure
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 was a joke.
I guess 1) is fine now. 2) should be done when FastFPE is
standard on Linux/ARM.
Why not just add an alternative regression output? pg_regress is
designed to handle it, and we have quite a few of those already to deal
with minor FP differences.
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.
Here are Jim's FastFPE 'point' results in separate file.
Unfortunately I have not an ARM machine to test it on.
Jim, could you apply this patch and run 'make check' on the
FastFPE kernel. If you encounter more small FP errors,
then simply copy results/test.out to expected/test_X.out
where X is a next free number.
Then send resulting files to this list.
--
marko
*** /dev/null 2005-01-04 07:18:19.0 +0200
--- src/test/regress/expected/point_1.out 2005-01-06 19:58:45.0
+0200
***
*** 0
--- 1,225
+ --
+ -- POINT
+ --
+ CREATE TABLE POINT_TBL(f1 point);
+ INSERT INTO POINT_TBL(f1) VALUES ('(0.0,0.0)');
+ INSERT INTO POINT_TBL(f1) VALUES ('(-10.0,0.0)');
+ INSERT INTO POINT_TBL(f1) VALUES ('(-3.0,4.0)');
+ INSERT INTO POINT_TBL(f1) VALUES ('(5.1, 34.5)');
+ INSERT INTO POINT_TBL(f1) VALUES ('(-5.0,-12.0)');
+ -- bad format points
+ INSERT INTO POINT_TBL(f1) VALUES ('asdfasdf');
+ ERROR: invalid input syntax for type point: asdfasdf
+ INSERT INTO POINT_TBL(f1) VALUES ('10.0,10.0');
+ INSERT INTO POINT_TBL(f1) VALUES ('(10.0 10.0)');
+ ERROR: invalid input syntax for type point: (10.0 10.0)
+ INSERT INTO POINT_TBL(f1) VALUES ('(10.0,10.0');
+ ERROR: invalid input syntax for type point: (10.0,10.0
+ SELECT '' AS six, POINT_TBL.*;
+ six | f1
+ -+
+ | (0,0)
+ | (-10,0)
+ | (-3,4)
+ | (5.1,34.5)
+ | (-5,-12)
+ | (10,10)
+ (6 rows)
+
+ -- left of
+ SELECT '' AS three, p.* FROM POINT_TBL p WHERE p.f1 '(0.0, 0.0)';
+ three |f1
+ ---+--
+| (-10,0)
+| (-3,4)
+| (-5,-12)
+ (3 rows)
+
+ -- right of
+ SELECT '' AS three, p.* FROM POINT_TBL p WHERE '(0.0,0.0)' p.f1;
+ three |f1
+ ---+--
+| (-10,0)
+| (-3,4)
+| (-5,-12)
+ (3 rows)
+
+ -- above
+ SELECT '' AS one, p.* FROM POINT_TBL p WHERE '(0.0,0.0)' ^ p.f1;
+ one |f1
+ -+--
+ | (-5,-12)
+ (1 row)
+
+ -- below
+ SELECT '' AS one, p.* FROM POINT_TBL p WHERE p.f1 ^ '(0.0, 0.0)';
+ one |f1
+ -+--
+ | (-5,-12)
+ (1 row)
+
+ -- equal
+ SELECT '' AS one, p.* FROM POINT_TBL p WHERE p.f1 ~= '(5.1, 34.5)';
+ one | f1
+ -+
+ | (5.1,34.5)
+ (1 row)
+
+ -- point in box
+ SELECT '' AS three, p.* FROM POINT_TBL p
+WHERE p.f1 @ box '(0,0,100,100)';
+ three | f1
+ ---+
+| (0,0)
+| (5.1,34.5)
+| (10,10)
+ (3 rows)
+
+ SELECT '' AS three, p.* FROM POINT_TBL p
+WHERE not p.f1 @ box '(0,0,100,100)';
+ three |f1
+ ---+--
+| (-10,0)
+| (-3,4)
+| (-5,-12)
+ (3 rows)
+
+ SELECT '' AS two, p.* FROM POINT_TBL p
+WHERE p.f1 @ path '[(0,0),(-10,0),(-10,10)]';
+ two | f1
+ -+-
+ | (0,0)
+ | (-10,0)
+ (2 rows)
+
+ SELECT '' AS six, p.f1, p.f1 - point '(0,0)' AS dist
+FROM POINT_TBL p
+ORDER BY dist;
+ six | f1 | dist
+ -++--
+ | (0,0) |0
+ | (-3,4) |5
+ | (-10,0)| 10
+ | (-5,-12) | 13
+ | (10,10)| 14.1421356237309
+ | (5.1,34.5) | 34.8749193547455
+ (6 rows)
+
+ SET geqo TO 'off';
+ SELECT '' AS thirtysix, p1.f1 AS point1, p2.f1 AS point2, p1.f1 - p2.f1 AS
dist
+FROM POINT_TBL p1, POINT_TBL p2
+ORDER BY dist, point1 using , point2 using ;
+ thirtysix | point1 | point2 | dist
+ ---+++--
+| (-10,0)| (-10,0)|0
+| (-5,-12) | (-5,-12) |0
+| (-3,4) | (-3,4) |0
+| (0,0) | (0,0) |0
+| (5.1,34.5) | (5.1,34.5) |0
+| (10,10)| (10,10)|0
+| (-3,4) | (0,0) |5
+| (0,0) | (-3,4) |5
+| (-10,0)| (-3,4) | 8.06225774829855
+| (-3,4) | (-10,0)|
Re: [HACKERS] CSV arm check failure
Marko Kreen marko@l-t.ee 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, because on most other platforms this behavior is probably a bug, and altering the tests like that would mask the bug. 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). 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 really a problem, fine, but that doesn't mean we should mask the same symptom everywhere. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] CSV arm check failure
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 really a problem, fine, but that doesn't mean we should mask the same symptom everywhere. I don't want to mask anything that shouldn't be. I made the suggestion in this particular case because we already have a number of alternative result files caused by FP differences. 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, although that would be a pity, to say the least. cheers andrew ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] CSV arm check failure
On Thu, Jan 06, 2005 at 02:05:17PM -0500, Tom Lane wrote:
Marko Kreen marko@l-t.ee 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, because on most other platforms this behavior
is probably a bug, and altering the tests like that would mask the bug.
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.
--
marko
Index: src/test/regress/pg_regress.sh
===
RCS file: /projects/cvsroot/pgsql/src/test/regress/pg_regress.sh,v
retrieving revision 1.51
diff -u -c -r1.51 pg_regress.sh
*** src/test/regress/pg_regress.sh 12 Dec 2004 15:34:15 - 1.51
--- src/test/regress/pg_regress.sh 6 Jan 2005 19:30:52 -
***
*** 669,681
# to a system-specific expected file.
# There shouldn't be multiple matches, but take the last if there are.
! EXPECTED=$inputdir/expected/${name}
for LINE in $SUBSTLIST
do
if [ `expr $LINE : $name=` -ne 0 ]
then
! SUBST=`echo $LINE | sed 's/^.*=//'`
! EXPECTED=$inputdir/expected/${SUBST}
fi
done
--- 669,680
# to a system-specific expected file.
# There shouldn't be multiple matches, but take the last if there are.
! SUBST_VALS=${name}
for LINE in $SUBSTLIST
do
if [ `expr $LINE : $name=` -ne 0 ]
then
! SUBST_VALS=`echo $LINE | sed -e 's/^.*=//' -e 's/,/ /g'`
fi
done
***
*** 684,701
bestfile=
bestdiff=
! result=2
! for thisfile in $EXPECTED.out ${EXPECTED}_[0-9].out; do
! [ ! -r $thisfile ] continue
! diff $DIFFFLAGS $thisfile $outputdir/results/${name}.out
/dev/null 21
! result=$?
case $result in
0) break;;
- 1) thisdiff=`diff $DIFFFLAGS $thisfile
$outputdir/results/${name}.out | wc -l`
-if [ -z $bestdiff ] || [ $thisdiff -lt $bestdiff ];
then
-bestdiff=$thisdiff; bestfile=$thisfile
-fi
-continue;;
2) break;;
esac
done
--- 683,707
bestfile=
bestdiff=
! for SUBST in $SUBST_VALS; do
! EXPECTED=$inputdir/expected/${SUBST}
! result=2
! for thisfile in $EXPECTED.out ${EXPECTED}_[0-9].out; do
! [ ! -r $thisfile ] continue
! diff $DIFFFLAGS $thisfile $outputdir/results/${name}.out
/dev/null 21
! result=$?
! case $result in
! 0) break;;
! 1) thisdiff=`diff $DIFFFLAGS $thisfile
$outputdir/results/${name}.out | wc -l`
!if [ -z $bestdiff ] || [ $thisdiff -lt $bestdiff
]; then
!bestdiff=$thisdiff; bestfile=$thisfile
!fi
!continue;;
! 2) break;;
! esac
! done
case $result in
0) break;;
2) break;;
esac
done
Index: src/test/regress/resultmap
===
RCS file: /projects/cvsroot/pgsql/src/test/regress/resultmap,v
retrieving revision 1.79
diff -u -c -r1.79 resultmap
*** src/test/regress/resultmap 23 Dec 2004 03:49:40 - 1.79
--- src/test/regress/resultmap 6 Jan 2005 19:30:52 -
***
*** 9,11
--- 9,12
float8/i.86-pc-cygwin=float8-small-is-zero
int8/.*-qnx=int8-exp-three-digits
int8/i.86-pc-mingw32=int8-exp-three-digits
+ point/arm.*-linux-gnu=point,point-fastfpe
*** /dev/null 2005-01-04 07:18:19.0 +0200
--- src/test/regress/expected/point-fastfpe.out 2005-01-06 19:58:45.0
+0200
***
*** 0
--- 1,225
+ --
+ -- POINT
+ --
+ CREATE TABLE POINT_TBL(f1 point);
+ INSERT INTO POINT_TBL(f1) VALUES ('(0.0,0.0)');
+ INSERT INTO POINT_TBL(f1) VALUES ('(-10.0,0.0)');
+ INSERT INTO POINT_TBL(f1) VALUES ('(-3.0,4.0)');
+ INSERT INTO POINT_TBL(f1) VALUES ('(5.1, 34.5)');
+ INSERT INTO POINT_TBL(f1) VALUES ('(-5.0,-12.0)');
+ -- bad format points
+ INSERT INTO POINT_TBL(f1) VALUES ('asdfasdf');
+ ERROR: invalid input syntax for type point: asdfasdf
+ INSERT INTO POINT_TBL(f1) VALUES ('10.0,10.0');
+ INSERT INTO POINT_TBL(f1) VALUES ('(10.0
Re: [HACKERS] oldish libpq bug still in RC2
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 interpreter Ah, of course. Thanks for the test scaffold. I have checked and committed a fix. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] PostgreSQL 8.0.0 Release Scheduale
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 1am GMT (around 9pm my time, around 5pm Josh's (Pacific) time, if I recall my time zone's correctly) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Porting/platforms/buildfarm open issues
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 idea on all platforms after all :-( Due to odd behavior of 'mkdir -p' command, I got below error when 'make install': mkdir -p -- /usr/local/pgsql/bin /usr/local/pgsql/share mkdir: cannot create /usr/local/pgsql/share. I think you ought to report this as a bug in the local version of mkdir. bash-2.05b$ diff backend/Makefile.DIST backend/Makefile 184c184 $(mkinstalldirs) $(DESTDIR)$(bindir) $(DESTDIR)$(datadir) --- $(mkinstalldirs) $(DESTDIR)$(datadir) $(DESTDIR)$(bindir) I'm not following the point of this change? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] PostgreSQL 8.0.0 Release Scheduale
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 1am GMT (around 9pm my time, around 5pm Josh's (Pacific) time, if I recall my time zone's correctly) As long as the APPDATA-files-on-win32 is finished off, I'm fine. Seems Tom is on that right now, so I don't doubti t will be. 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 - there is always a bit of a delay before packagers pick it up. I know there is at least for the MSI package for windows, but I'm sure there also is for RPM etc. So people running off those will have even less time to test..) I'm definitly not saying drag this out a long time, but perhaps two more days or so? //Magnus ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] PostgreSQL 8.0.0 Release Scheduale
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 - there is always a bit of a delay before packagers pick it up. I know there is at least for the MSI package for windows, but I'm sure there also is for RPM etc. So people running off those will have even less time to test..) I'm definitly not saying drag this out a long time, but perhaps two more days or so? Why not just release rc4 and wait a week. Then 8.0 would be released next friday. J //Magnus ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Command Prompt, Inc., home of PostgreSQL Replication, and plPHP. Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL begin:vcard fn:Joshua D. Drake n:Drake;Joshua D. org:Command Prompt, Inc. adr:;;PO Box 215;Cascade Locks;Oregon;97014;USA email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 note:Command Prompt, Inc. is the largest and oldest US based commercial PostgreSQL support provider. We provide the only commercially viable integrated PostgreSQL replication solution, but also custom programming, and support. We authored the book Practical PostgreSQL, the procedural language plPHP, and adding trigger capability to plPerl. x-mozilla-html:FALSE url:http://www.commandprompt.com/ version:2.1 end:vcard ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL 8.0.0 Release Scheduale
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 planning on packaging up RC4 tonight around 1am GMT (around 9pm my time, around 5pm Josh's (Pacific) time, if I recall my time zone's correctly) As long as the APPDATA-files-on-win32 is finished off, I'm fine. Seems Tom is on that right now, so I don't doubti t will be. 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 - there is always a bit of a delay before packagers pick it up. I know there is at least for the MSI package for windows, but I'm sure there also is for RPM etc. So people running off those will have even less time to test..) I'm definitly not saying drag this out a long time, but perhaps two more days or so? I agree Magnus has a point here. We just did major changes for Win32 configuration file locations and it seems it is a mistake to not have sufficient time for testing and to see if something else comes up. I think we should shoot for the end of next week. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [Testperf-general] pg_autovacuum w/ dbt2
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 -d4, where the output can be seen here: http://www.osdl.org/projects/dbt2dev/results/dev4-010/236/dbt2.out I, uh, wasn't able to reproduce the previous errors after repairing my filesystems after a power outage. So I figure that might be good news. The performance is up from run 215 with the errors, so I'll continue with trying to tune some of the pg_autovacuum values. Mark On Tue, Dec 21, 2004 at 09:41:31AM -0800, Mark Wong wrote: After all this time I finally got around to vacuuming the database with dbt2 with pg_autovacuum. :) http://www.osdl.org/projects/dbt2dev/results/dev4-010/215/ Doesn't look so good though, probably because I'm not using optimal settings with pg_autovacuum. So far I have only tried the default settings (running without any arguments, except -D). The only thing that's peculiar is a number of unexpected rollbacks across all of the transactions. I suspect it was something to do with these messages coming from pg_autovacuum: [2004-12-20 15:48:18 PST] ERROR: Can not refresh statistics information from the database dbt2. [2004-12-20 15:48:18 PST] The error is [ERROR: failed to re-find parent key in pk_district ] This is with 8.0rc1. I can get rc2 installed since it just came out. So let me know what I can try and what not. Mark ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] CSV arm check failure
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 thinking along the same lines. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] PostgreSQL 8.0.0 Release Scheduale
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 know ASAP ... I'm planning on packaging up RC4 tonight around 1am GMT (around 9pm my time, around 5pm Josh's (Pacific) time, if I recall my time zone's correctly) As long as the APPDATA-files-on-win32 is finished off, I'm fine. Seems Tom is on that right now, so I don't doubti t will be. 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 - there is always a bit of a delay before packagers pick it up. I know there is at least for the MSI package for windows, but I'm sure there also is for RPM etc. So people running off those will have even less time to test..) I'm definitly not saying drag this out a long time, but perhaps two more days or so? I agree Magnus has a point here. We just did major changes for Win32 configuration file locations and it seems it is a mistake to not have sufficient time for testing and to see if something else comes up. I think we should shoot for the end of next week. 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? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] RC4 bundled and available ...
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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] Bgwriter behavior
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 info that could allow the bgwriter settings to be tuned. Uh, what does this do exactly? Add additional logging output? Produces output like this... DEBUG:ARC T1target= 45 B1len= 4954 T1len= 40 T2len= 4960 B2len= 46 DEBUG:ARC total = 98% B1hit= 0% T1hit= 0% T2hit= 98% B2hit= 0% DEBUG:ARC buffer dirty misses= 22% (wasted=0); cleaned= 4494 when you have debug_shared_buffers (= n) set and you have server messages DEBUG1 available. The last line of log output has been replaced by this version. -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] CSV arm check failure
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, although that would be a pity, to say the least. What would you think about setting up a few columns to show the results of the various stages, rather than just the single result? Each row might get a little long, but then you can easily see if the other stages (beyond the first problem) work as well. I've been trying to think of a way to shorten the system information, but haven't thought of anything wonderful yet. Best, Michael Glaesemann grzm myrealbox com ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] PostgreSQL 8.0.0 Release Scheduale
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 experience that Monday releases don't get much exposure... people are trying to catch up after the weekend. However I do like the theory :) Sincerely, Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL begin:vcard fn:Joshua Drake n:Drake;Joshua org:Command Prompt, Inc. adr:;;PO Box 215 ;Cascade Locks;OR;97014;US email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 x-mozilla-html:FALSE url:http://www.commandprompt.com version:2.1 end:vcard ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL 8.0.0 Release Scheduale
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 that we would then want a tuesday release. It is my experience that Monday releases don't get much exposure... people are trying to catch up after the weekend. Having the release earlier in the week also means there will probably be more people online to quickly respond to any issues that arise with the release. Then again, it also means its more likely more people will be exposed to any such issues as well. Weighing the two, I'd think former is preferable to the latter. (Not that there'll be any issues anyway :) Michael Glaesemann grzm myrealbox com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
