Re: [HACKERS] Re: Call for platforms
On Mon, Apr 09, 2001 at 11:41:55AM -0700, Henry B. Hotz wrote: At 1:50 AM -0400 4/6/01, Tom Lane wrote: ... What version of libreadline do you have installed, and how does it declare completion_matches()? I have whatever is standard on NetBSD 1.5. I noticed that configure found a readline.h include file, but NetBSD doesn't integrate the current GNU implementation. I did not do a test of psql to see if the feature worked. I'm sure you could "fix" this problem if you installed GNU readline and referenced it in the build. Since Solaris had even worse issues with needing GNU support utilities installed this didn't seem like a big deal to me. OTOH it could confuse a new user. Odd: I am using the standard NetBSD readline found in -ledit and it is fine.. Can it be a -1.5 vs -current difference? I have just stumbled across something which is broken though: NetBSD-1.5S/arm32: % ldd `which psql` /usr/local/pgsql/bin/psql: -lpq.2 = /usr/local/pgsql/lib/libpq.so.2.1 (0x2003b000) -lz.0 = /usr/lib/libz.so.0.2 (0x20048000) -lcrypt.0 = /usr/lib/libcrypt.so.0.0 (0x20056000) -lresolv.1 = /usr/lib/libresolv.so.1.0 (0x2005c000) -lm.0 = /usr/lib/libm.so.0.1 (0x20065000) -lutil.5 = /usr/lib/libutil.so.5.5 (0x2008b000) -ledit.2 = /usr/lib/libedit.so.2.5 (0x20096000) -lc.12 = /usr/lib/libc.so.12.74 (0x200ae000) NetBSD-1.5U/i386: % ldd `which psql` /usr/local/pgsql/bin/psql: -lcrypt.0 = /usr/lib/libcrypt.so.0 -lresolv.1 = /usr/lib/libresolv.so.1 -lpq.2 = /usr/local/pgsql/lib/libpq.so.2 -lz.0 = /usr/lib/libz.so.0 -lm.0 = /usr/lib/libm387.so.0 -lm.0 = /usr/lib/libm.so.0 -lutil.5 = /usr/lib/libutil.so.5 -ledit.2 = /usr/lib/libedit.so.2 -ltermcap.0 = /usr/lib/libtermcap.so.0 -lc.12 = /usr/lib/libc.so.12 -ltermcap is missing from arm32 - it's necessary if libedit is going to find _tgetent.. Investigating now.. Cheers, Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: Call for platforms
Did we decide that "most NetBSD/i386 users have fpus" in which case Marko's patch should be applied? I'm unclear on what y'all mean by "i386 + fpu", especially since NetBSD seems to insist on calling every Intel processor a "i386". In this case, are you suggesting that this patch covers all NetBSD installations on every Intel processor from i386 + fpu forward to i486, i586, etc etc? Or is this specifically for the i386 with the 80387 coprocessor which is how any reasonable person would interpret "i386+fpu"? ;) - Thomas Index: src/test/regress/resultmap === RCS file: /home/projects/pgsql/cvsroot/pgsql/src/test/regress/resultmap,v retrieving revision 1.45 diff -u -r1.45 resultmap --- src/test/regress/resultmap2001/03/22 15:13:18 1.45 +++ src/test/regress/resultmap2001/03/22 17:29:49 @@ -17,6 +17,7 @@ geometry/.*-openbsd=geometry-positive-zeros-bsd geometry/.*-irix6=geometry-irix geometry/.*-netbsd=geometry-positive-zeros +geometry/i.86-.*-netbsdelf1.5=geometry-positive-zeros-bsd geometry/.*-sysv5uw7.*:cc=geometry-uw7-cc geometry/.*-sysv5uw7.*:gcc=geometry-uw7-gcc geometry/alpha.*-dec-osf=geometry-alpha-precision ---(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
[HACKERS] Re: Call for platforms
On Fri, Apr 13, 2001 at 01:25:45PM +, Thomas Lockhart wrote: Did we decide that "most NetBSD/i386 users have fpus" in which case Marko's patch should be applied? I'm unclear on what y'all mean by "i386 + fpu", especially since NetBSD seems to insist on calling every Intel processor a "i386". History ;-) In this case, are you suggesting that this patch covers all NetBSD installations on every Intel processor from i386 + fpu forward to i486, i586, etc etc? Yes! It's simply, if the peecee type thing has a fpu (as in the sysctl machdep.fpu_present returns 1), then libm387.so is used, and you get differences in the (from memory 44th insignificant figure?) otherwise it just uses libm.so and you get what is currently correct in resultmap. Cheers, Patrick ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Call for platforms
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 `initialize_readline':
tab-complete.c:103: warning: assignment from incompatible pointer type
tab-complete.c: In function `psql_completion':
tab-complete.c:292: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
tab-complete.c:296: warning: passing arg 2 of `completion_matches'
from incompatible pointer type
What version of libreadline do you have installed, and how does it
declare completion_matches()?
$ uname -srm
NetBSD 1.5 i386
$ grep CPFunction /usr/include/readline.h
typedef char *CPFunction __P((const char *, int));
extern CPFunction *rl_completion_entry_function;
char **completion_matches __P((const char *, CPFunction *));
Putting the 'const' in the relevant PostgreSQL functions (diff against
7.1RC3 below) removes these warnings. I don't know what that does on
a machine using GNU readline ... I can check that in a day or two if
anyone's interested.
The NetBSD libedit-emulating-readline works just fine with psql even
without the warnings fixed -- they're harmless in this case.
Regards,
Giles
*** src/bin/psql/tab-complete.c-origMon Apr 2 05:17:32 2001
--- src/bin/psql/tab-complete.c Tue Apr 10 19:51:21 2001
***
*** 70,80
/* Forward declaration of functions */
! static char **psql_completion(char *text, int start, int end);
! static char *create_command_generator(char *text, int state);
! static char *complete_from_query(char *text, int state);
! static char *complete_from_const(char *text, int state);
! static char *complete_from_list(char *text, int state);
static PGresult *exec_query(char *query);
char *quote_file_name(char *text, int match_type, char *quote_pointer);
--- 70,80
/* Forward declaration of functions */
! static char **psql_completion(const char *text, int start, int end);
! static char *create_command_generator(const char *text, int state);
! static char *complete_from_query(const char *text, int state);
! static char *complete_from_const(const char *text, int state);
! static char *complete_from_list(char const *text, int state);
static PGresult *exec_query(char *query);
char *quote_file_name(char *text, int match_type, char *quote_pointer);
***
*** 177,183
libraries completion_matches() function, so we don't have to worry about it.
*/
static char **
! psql_completion(char *text, int start, int end)
{
/* This is the variable we'll return. */
char **matches = NULL;
--- 177,183
libraries completion_matches() function, so we don't have to worry about it.
*/
static char **
! psql_completion(const char *text, int start, int end)
{
/* This is the variable we'll return. */
char **matches = NULL;
***
*** 796,802
as defined above.
*/
static char *
! create_command_generator(char *text, int state)
{
static int list_index,
string_length;
--- 796,802
as defined above.
*/
static char *
! create_command_generator(const char *text, int state)
{
static int list_index,
string_length;
***
*** 829,835
etc.
*/
static char *
! complete_from_query(char *text, int state)
{
static int list_index,
string_length;
--- 829,835
etc.
*/
static char *
! complete_from_query(const char *text, int state)
{
static int list_index,
string_length;
***
*** 877,883
SQL words that can appear at certain spot.
*/
static char *
! complete_from_list(char *text, int state)
{
static int string_length,
list_index;
--- 877,883
SQL words that can appear at certain spot.
*/
static char *
! complete_from_list(const char *text, int state)
{
static int string_length,
list_index;
***
*** 911,917
The string to be passed must be in completion_charp.
*/
static char *
! complete_from_const(char *text, int state)
{
(void) text;/* We don't care about what was entered
* already. */
--- 911,917
The string to be passed must be in completion_charp.
*/
static char *
! complete_from_const(const char *text, int state)
{
(void) text;/* We don't care about what was entered
* already. */
---(end of
Re: [HACKERS] Re: Call for platforms
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 `initialize_readline': tab-complete.c:103: warning: assignment from incompatible pointer type tab-complete.c: In function `psql_completion': tab-complete.c:292: warning: passing arg 2 of `completion_matches' from incompatible pointer type tab-complete.c:296: warning: passing arg 2 of `completion_matches' from incompatible pointer type What version of libreadline do you have installed, and how does it declare completion_matches()? I have whatever is standard on NetBSD 1.5. I noticed that configure found a readline.h include file, but NetBSD doesn't integrate the current GNU implementation. I did not do a test of psql to see if the feature worked. I'm sure you could "fix" this problem if you installed GNU readline and referenced it in the build. Since Solaris had even worse issues with needing GNU support utilities installed this didn't seem like a big deal to me. OTOH it could confuse a new user. Signature held pending an ISO 9000 compliant signature design and approval process. [EMAIL PROTECTED], or [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Call for platforms
Giles Lean [EMAIL PROTECTED] writes: It is still necessary to add -ltermcap after -ledit in src/Makefile.global to have functional history editing in psql. This is a weakness in the configure script: it goes through a loop where it tries to link a program that calls readline() with, in order, "-lreadline", "-lreadline -ltermcap", "-lreadline -lncurses", "-lreadline -lcurses", "-ledit", "-ledit -ltermcap", "-ledit -lncurses" and "-ledit -lcurses". The first link that succeeds wil determine which libraries are used. However, on some platforms with dynamic libraries, the link will succeed as soon as readline() is present -- but the shared library that contains it doesn't contain a complete specification of all other libraries it needs at run-time (the executable is expected to hold this information), and the program fails at run-time even though it linked without any error message. I don't know how the situation could best be improved, though... -tih -- The basic difference is this: hackers build things, crackers break them. ---(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] Re: Call for platforms
Tom Ivar Helbekkmo writes: Giles Lean [EMAIL PROTECTED] writes: It is still necessary to add -ltermcap after -ledit in src/Makefile.global to have functional history editing in psql. This is a weakness in the configure script: it goes through a loop where it tries to link a program that calls readline() with, in order, "-lreadline", "-lreadline -ltermcap", "-lreadline -lncurses", "-lreadline -lcurses", "-ledit", "-ledit -ltermcap", "-ledit -lncurses" and "-ledit -lcurses". The first link that succeeds wil determine which libraries are used. However, on some platforms with dynamic libraries, the link will succeed as soon as readline() is present -- but the shared library that contains it doesn't contain a complete specification of all other libraries it needs at run-time (the executable is expected to hold this information), and the program fails at run-time even though it linked without any error message. On such a platform it would hardly be possible to detect anything with any reliably. A linker that links a program "succesfully" while the program really needs more libraries to be runnable isn't very useful. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Call for platforms
Peter Eisentraut [EMAIL PROTECTED] writes:
On such a platform it would hardly be possible to detect anything with any
reliably. A linker that links a program "succesfully" while the program
really needs more libraries to be runnable isn't very useful.
You're right, of course -- it's a bug in the linkage loader on the
platform in question. NetBSD/vax has it:
$ uname -a
NetBSD varg.i.eunet.no 1.5T NetBSD 1.5T (VARG) #4: Thu Apr 5 23:38:04 CEST 2001
[EMAIL PROTECTED]:/usr/src/sys/arch/vax/compile/VARG vax
$ cat foo.c
int main (int argc, char **argv) { readline(); }
$ cc -o foo foo.c
/tmp/ccFTO4Mu.o: Undefined symbol `_readline'referenced from text segment
collect2: ld returned 1 exit status
$ cc -o foo foo.c -ledit
$ echo $?
0
$ ./foo
/usr/libexec/ld.so: Undefined symbol "_tputs"in foo:/usr/lib/libedit.so.2.5
$ echo $?
1
$ ldd foo
foo:
-ledit.2 = /usr/lib/libedit.so.2.5 (0x181b000)
-lc.12 = /usr/lib/libc.so.12.74 (0x182d000)
$
-tih
--
The basic difference is this: hackers build things, crackers break them.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: Call for platforms
Thanks! I'm not too worried about 1.4.2, but be sure to let us know what the problem was; it may help out someone else... NetBSD-1.4.2/i386 passes all tests with 7.1RC3. My previous test failure on this platform was due to the timezone information on the test system not being standard; once that was corrected all tests pass. It is still necessary to add -ltermcap after -ledit in src/Makefile.global to have functional history editing in psql. Regards, Giles ---(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
[HACKERS] Re: Call for platforms
Tom Ivar Helbekkmo [EMAIL PROTECTED] writes:
We need some NetBSD folks to speak up!
I've once again got a VAX that should be able to run PostgreSQL on
NetBSD/vax, so I hope to be able to help revitalize that port soon...
It still works. RC1 configures, compiles and runs on my VAX 4000/500
with NetBSD-current -- but the regression tests give a lot of failures
because the VAX doesn't have IEEE math, leading to different rounding
and erroneous assumptions about the limits of floating point values.
I'll be looking at this more closely.
Also, dynamic loading now works on NetBSD/vax, so my old #ifdef for
that in the backend/port/bsd.c file, which has since propagated into
the new *bsd.c files, can go away (actually, I'm suspicious of the
MIPS part of those, too, but I didn't put that in, and I don't have
any MIPS-based machines):
Index: src/backend/port/dynloader/freebsd.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/port/dynloader/freebsd.c,v
retrieving revision 1.9
diff -c -r1.9 freebsd.c
*** src/backend/port/dynloader/freebsd.c2001/02/10 02:31:26 1.9
--- src/backend/port/dynloader/freebsd.c2001/04/01 08:01:20
***
*** 63,69
void *
BSD44_derived_dlopen(const char *file, int num)
{
! #if defined(__mips__) || (defined(__NetBSD__) defined(__vax__))
sprintf(error_message, "dlopen (%s) not supported", file);
return NULL;
#else
--- 63,69
void *
BSD44_derived_dlopen(const char *file, int num)
{
! #if defined(__mips__)
sprintf(error_message, "dlopen (%s) not supported", file);
return NULL;
#else
***
*** 78,84
void *
BSD44_derived_dlsym(void *handle, const char *name)
{
! #if defined(__mips__) || (defined(__NetBSD__) defined(__vax__))
sprintf(error_message, "dlsym (%s) failed", name);
return NULL;
#else
--- 78,84
void *
BSD44_derived_dlsym(void *handle, const char *name)
{
! #if defined(__mips__)
sprintf(error_message, "dlsym (%s) failed", name);
return NULL;
#else
***
*** 101,107
void
BSD44_derived_dlclose(void *handle)
{
! #if defined(__mips__) || (defined(__NetBSD__) defined(__vax__))
#else
dlclose(handle);
#endif
--- 101,107
void
BSD44_derived_dlclose(void *handle)
{
! #if defined(__mips__)
#else
dlclose(handle);
#endif
Index: src/backend/port/dynloader/netbsd.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/port/dynloader/netbsd.c,v
retrieving revision 1.3
diff -c -r1.3 netbsd.c
*** src/backend/port/dynloader/netbsd.c 2001/02/10 02:31:26 1.3
--- src/backend/port/dynloader/netbsd.c 2001/04/01 08:01:20
***
*** 63,69
void *
BSD44_derived_dlopen(const char *file, int num)
{
! #if defined(__mips__) || (defined(__NetBSD__) defined(__vax__))
sprintf(error_message, "dlopen (%s) not supported", file);
return NULL;
#else
--- 63,69
void *
BSD44_derived_dlopen(const char *file, int num)
{
! #if defined(__mips__)
sprintf(error_message, "dlopen (%s) not supported", file);
return NULL;
#else
***
*** 78,84
void *
BSD44_derived_dlsym(void *handle, const char *name)
{
! #if defined(__mips__) || (defined(__NetBSD__) defined(__vax__))
sprintf(error_message, "dlsym (%s) failed", name);
return NULL;
#elif defined(__ELF__)
--- 78,84
void *
BSD44_derived_dlsym(void *handle, const char *name)
{
! #if defined(__mips__)
sprintf(error_message, "dlsym (%s) failed", name);
return NULL;
#elif defined(__ELF__)
***
*** 101,107
void
BSD44_derived_dlclose(void *handle)
{
! #if defined(__mips__) || (defined(__NetBSD__) defined(__vax__))
#else
dlclose(handle);
#endif
--- 101,107
void
BSD44_derived_dlclose(void *handle)
{
! #if defined(__mips__)
#else
dlclose(handle);
#endif
Index: src/backend/port/dynloader/openbsd.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/port/dynloader/openbsd.c,v
retrieving revision 1.3
diff -c -r1.3 openbsd.c
*** src/backend/port/dynloader/openbsd.c2001/02/10 02:31:26 1.3
--- src/backend/port/dynloader/openbsd.c2001/04/01 08:01:20
***
*** 63,69
void *
BSD44_derived_dlopen(const char *file, int num)
{
! #if defined(__mips__) || (defined(__NetBSD__) defined(__vax__))
sprintf(error_message, "dlopen (%s) not supported", file);
return NULL;
#else
--- 63,69
void *
BSD44_derived_dlopen(const char *file, int num)
{
! #if defined(__mips__)
sprintf(error_message, "dlopen (%s) not supported", file);
return NULL;
#else
***
*** 78,84
void *
Re: [HACKERS] Re: Call for platforms
At 12:27 AM 3/28/01 -0500, Tom Lane wrote:
That would fix it for ARM but not for anyplace else with similar
alignment behavior. Would you try this patch instead to see what
happens?
I don't think this solution would be valid on many other platforms. It forces the
structure to not be padded, and assumes that the cpu will be able to fetch from
unaligned boundaries. The only reason this works is that the arm linux kernel contains
an alignment trap handler that catches the fault and does a fixup on the access.
Otherwise it would crash with SIGBUS.
static FormData_pg_attribute a1 = {
! 0x, {"ctid"}, TIDOID, 0, SizeOfIptrData,
SelfItemPointerAttributeNumber, 0, -1, -1, '\0', 'p', '\0', 'i', '\0', '\0'
};
Well, this patch seems to produce attlens of 6 as desired, but it causes many (13) of
the regression tests to fail. Do you want to see the regression.diffs?
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
[HACKERS] Re: Call for platforms
mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii Any luck with RC1? I will try today or tomorrow... -- Tatsuo Ishii ---(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] Re: Call for platforms
Thus spake Tom Ivar Helbekkmo
We need some NetBSD folks to speak up!
I have successfully compiled it from CVS sources on my NetBSD -current but
I can't find the tar file for RC1 to try it with the package system. Can
someone point me to it please.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(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] Re: Call for platforms
On Tue, Mar 27, 2001 at 06:36:37AM -0500, D'Arcy J.M. Cain allegedly wrote: Thus spake Tom Ivar Helbekkmo We need some NetBSD folks to speak up! I have successfully compiled it from CVS sources on my NetBSD -current but I can't find the tar file for RC1 to try it with the package system. Can someone point me to it please. It's probably in /pub/dev (or something similar) on the ftp server... Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Call for platforms
We just fixed that yesterday. Can you grab the most recent CVS and give it a try? One that didn't compilei RC1: BIGBOY 71# uname -a IRIX BIGBOY 6.5 05190003 IP22 On an Indigo2 (R4000), gcc 2.95.2 , with the following error: gcc -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -U_NO_XOPEN4 -c s_lock.c -o s_lock.o s_lock.c: In function `s_lock': s_lock.c:134: warning: passing arg 1 of pointer to function discards qualifiers from pointer target type s_lock.c: In function `tas_dummy': s_lock.c:235: parse error before `_volatile__' s_lock.c: At top level: s_lock.c:234: warning: `tas_dummy' defined but not used gmake[4]: *** [s_lock.o] Error 1 gmake[4]: Leaving directory `/usr/people/telmnstr/pg/postgresql-7.1RC1/src/backend/storage/buffer' gmake[3]: *** [buffer-recursive] Error 2 gmake[3]: Leaving directory `/usr/people/telmnstr/pg/postgresql-7.1RC1/src/backend/storage' gmake[2]: *** [storage-recursive] Error 2 gmake[2]: Leaving directory `/usr/people/telmnstr/pg/postgresql-7.1RC1/src/backend' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/usr/people/telmnstr/pg/postgresql-7.1RC1/src' gmake: *** [all] Error 2 *** Error code 2 (bu21) Jeff ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] Re: Call for platforms
Jeff Duffy [EMAIL PROTECTED] writes: s_lock.c:235: parse error before `_volatile__' That typo is fixed in current sources (should be OK in last night's snapshot) but there's still some doubt as to how well the MIPS assembly code works ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: Regression test on FBSD 3.3 4.2, IRIX 6.5 (was Re: [HACKERS]Re: Call for platforms)
Mathijs Brands writes: I just tried to compile 7.1RC1 on my IRIX 6.5 box using gcc 2.95.2. According to the information at http://freeware.sgi.com/shared/howto.html#b1 it probably won't work to compile PostgreSQL with GCC on Irix. Or it might work and crash when run. Be warned. (I think it is not accidental that no one ever successfully used a PostgreSQL/GCC/Irix combo.) -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
RE: [HACKERS] Re: Call for platforms
I've already reported this to the webpage, but I got a fail on the random test: random ... failed (ignored) This is on a stock RedHat 7.0 kernel box with the SMP kernel (but running a single processor): [pjm3@localhost regress]$ less regression.diffs *** ./expected/random.out Thu Jan 6 06:40:54 2000 --- ./results/random.outTue Mar 27 15:07:16 2001 *** *** 25,31 GROUP BY random HAVING count(random) 1; random | count +--- ! (0 rows) SELECT random FROM RANDOM_TBL WHERE random NOT BETWEEN 80 AND 120; --- 25,32 GROUP BY random HAVING count(random) 1; random | count +--- ! 99 | 2 ! (1 row) SELECT random FROM RANDOM_TBL WHERE random NOT BETWEEN 80 AND 120; == Regards, Phil +--+ | Phil Mayers, Network Support | | Centre for Computing Services| | Imperial College | +--+ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Call for platforms
"Mayers, Philip J" [EMAIL PROTECTED] writes: I've already reported this to the webpage, but I got a fail on the random test: random ... failed (ignored) See http://www.postgresql.org/devel-corner/docs/postgres/regress.html especially the last item ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Call for platforms
Mathijs Brands [EMAIL PROTECTED] writes: Even if you fix this it won't work (I tried it). Robert mailed why. Check the URL below for more information. It crashes on semctl :( http://freeware.sgi.com/shared/howto.html#b1 Ugh. Given the semctl compatibility problem, I suspect we'd better note in the platform list that IRIX is only supported for cc, not gcc. The other uncomfy-looking thing on that page is the very first item, about configure scripts picking up libraries that they'd best not. (I have seen similar issues on HPUX, although they were relatively easy to get around.) We might need to do some more hacking on our configure script to make it play nice on IRIX. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Call for platforms
Tom Ivar Helbekkmo [EMAIL PROTECTED] wrote: Thomas Lockhart [EMAIL PROTECTED] writes: NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo Fetching the latest source kit now -- hope to have regression tests run and a report back to you within a day or two. We need some NetBSD folks to speak up! I've once again got a VAX that should be able to run PostgreSQL on NetBSD/vax, so I hope to be able to help revitalize that port soon... it might also be a good idea to ask on the NetBSD ports lists - i think there will most probably some people trying things out - the name of the list is [EMAIL PROTECTED] where arch is the corresponding NetBSD port name (pmax, macppc, sparc, i386, arm32, ...) this might also be a good idea for the mips test-and-set thing (on the port-pmax list - there are a lot of people knowing all that stuff very well) also it might be worth to eventually ask on the [EMAIL PROTECTED] list for someone willing to play with PostgreSQL on FreeBSD/alpha just some ideas ... t -- thomas graichen [EMAIL PROTECTED] ... perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away. --- antoine de saint-exupery ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Call for platforms
mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii Any luck with RC1? I will try today or tomorrow... In summary no, improvemnets seen. If compiled with -O2 or -O2 -g, I got 10 tests FAILED. misc test failed due to a backend crash. The SQL caused the crash was: select i, length(t), octet_length(t), oldstyle_length(i,t) from oldstyle_test; #0 ExecReplace (slot=0x1a4a7d0, tupleid=0x0, estate=0x1a4a708) at execMain.c:1408 1408resultRelationDesc = resultRelInfo-ri_RelationDesc; (gdb) where #0 ExecReplace (slot=0x1a4a7d0, tupleid=0x0, estate=0x1a4a708) at execMain.c:1408 #1 0x188471c in ExecutePlan (estate=0x0, plan=0x1a4a410, operation=CMD_SELECT, numberTuples=0, direction=27567836, destfunc=0x1a4adf8) at execMain.c:1127 #2 0x188471c in ExecutePlan (estate=0x0, plan=0x1a4a410, operation=CMD_SELECT, numberTuples=0, direction=27567836, destfunc=0x1a4adf8) at execMain.c:1127 #3 0x18838b8 in ExecutorRun (queryDesc=0x1a4a7d0, estate=0x1a4a708, feature=27567784, count=0) at execMain.c:233 #4 0x18e7784 in ProcessQuery (parsetree=0x1a4a708, plan=0x1a4a6a8, dest=None) at pquery.c:295 #5 0x18e5c38 in pg_exec_query_string (query_string=0x1a4a410 "", dest=None, parse_context=0x1) at postgres.c:806 #6 0x18e70b8 in PostgresMain (argc=1, argv=0x0, real_argc=4, real_argv=0x0, username=0x0) at postgres.c:1902 #7 0x18c92ec in DoBackend (port=0x1a4a6a8) at postmaster.c:2111 #8 0x18c8e10 in BackendStartup (port=0x1a4a708) at postmaster.c:1894 #9 0x18c7c08 in ServerLoop () at postmaster.c:992 #10 0x18c74f4 in PostmasterMain (argc=0, argv=0x1a4a6a8) at postmaster.c:682 #11 0x1899a5c in main (argc=27567784, argv=0x1a4a708) at main.c:147 #12 0x181c400 in _start () (gdb) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Call for platforms
-BEGIN PGP SIGNED MESSAGE- On 26 Mar 2001, at 23:14, Tom Lane wrote: "Mark Knox" [EMAIL PROTECTED] writes: On 25 Mar 2001, at 16:07, Tom Lane wrote: Does that database have any user-created relations in it, or is it just a virgin database? Totally virgin. I created it just for that select you wanted. Okay. Would you create a couple of random tables in it and do the select again? I want to see what ctid looks like in a user-created table. Sure. I created two tables called 'test1' and 'test2'. Test1 has a single field 'field1' of type int4. Test2 has two fields 'field1' and 'field2' of types char(200) and int4 respectively. Here are the results: postgres= select p1.oid,attrelid,relname,attname,attlen,attalign,attbyval from pg_attribute p1, pg_class p2 where atttypid = 27 and p2.oid = attrelid order by 1; oid|attrelid|relname |attname|attlen|attalign|attbyval - -++--+---+--++ 16401|1247|pg_type |ctid | 6|i |f 16415|1262|pg_database |ctid | 6|i |f 16439|1255|pg_proc |ctid | 6|i |f 16454|1260|pg_shadow |ctid | 6|i |f 16464|1261|pg_group |ctid | 6|i |f 16486|1249|pg_attribute |ctid | 6|i |f 16515|1259|pg_class |ctid | 6|i |f 16526|1215|pg_attrdef|ctid | 6|i |f 16537|1216|pg_relcheck |ctid | 6|i |f 16557|1219|pg_trigger|ctid | 6|i |f 16572| 16567|pg_inherits |ctid | 8|i |f 16593| 16579|pg_index |ctid | 8|i |f 16610| 16600|pg_statistic |ctid | 8|i |f 16635| 16617|pg_operator |ctid | 8|i |f 16646| 16642|pg_opclass|ctid | 8|i |f 16678| 16653|pg_am |ctid | 8|i |f 16691| 16685|pg_amop |ctid | 8|i |f 16873| 16867|pg_amproc |ctid | 8|i |f 16941| 16934|pg_language |ctid | 8|i |f 16953| 16948|pg_largeobject|ctid | 8|i |f 16970| 16960|pg_aggregate |ctid | 8|i |f 17038| 17033|pg_ipl|ctid | 8|i |f 17051| 17045|pg_inheritproc|ctid | 8|i |f 17067| 17058|pg_rewrite|ctid | 8|i |f 17079| 17074|pg_listener |ctid | 8|i |f 17090| 17086|pg_description|ctid | 8|i |f 17206| 17201|pg_toast_1215 |ctid | 8|i |f 17221| 17216|pg_toast_17086|ctid | 8|i |f 17236| 17231|pg_toast_1255 |ctid | 8|i |f 17251| 17246|pg_toast_1216 |ctid | 8|i |f 17266| 17261|pg_toast_17058|ctid | 8|i |f 17281| 17276|pg_toast_16600|ctid | 8|i |f 17301| 17291|pg_user |ctid | 8|i |f 17314| 17309|pg_rules |ctid | 8|i |f 17327| 17322|pg_views |ctid | 8|i |f 17342| 17335|pg_tables |ctid | 8|i |f 17355| 17350|pg_indexes|ctid | 8|i |f 18724| 18721|test1 |ctid | 8|i |f 18735| 18731|test2 |ctid | 8|i |f (39 rows) I suspect it might be an alignment problem Sort of. I am suspicious that sizeof(ItemPointerData) is returning 8 rather than 6 as one might expect. Maybe it's padding the structure to a dword boundary? ARM is notorious for such things.. I will rebuild it with __attribute__((packed)) on the struct and see if the size changes.. -BEGIN PGP SIGNATURE- Version: N/A iQCVAwUBOsFDJP+IdJuhyV9xAQEKxQP/YJXTxZppLd7ECk4BSwDZaStP4+bE6acc StT//i/drdPC53DDWqiXLGA0bS384EXxyjvvaO1bTXzVFU/3+X/pY6YN/G3HMoah dbCXRli2Y57yansf1WaVmK1lhiAqLy3iGYFp2nZvO1Sl1u+ba89HtV+G+iaKZSTr U+HWTU3nnOM= =vkY+ -END PGP SIGNATURE- ---(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] Re: Call for platforms
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any another MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
File information ---
File: arm-alignment.patch
Date: 27 Mar 2001, 21:26
Size: 533 bytes.
Type: Unknown
arm-alignment.patch
---(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] Re: Call for platforms
-BEGIN PGP SIGNED MESSAGE- On 27 Mar 2001, at 20:49, Mark Knox wrote: I suspect it might be an alignment problem Sort of. I am suspicious that sizeof(ItemPointerData) is returning 8 rather than 6 as one might expect. Maybe it's padding the structure to a dword boundary? ARM is notorious for such things.. I will rebuild it with __attribute__((packed)) on the struct and see if the size changes.. Aha, progress! The packed directive gives attlen of 6 across the board! Type_sanity test passes now too, so the only failing regression test is geometry and that is easily dismissed. The variation is in the last decimal place and probably due to emulated floating point (ARM has no FPU). The patch is attached.. it's tiny but seems to be effective. -BEGIN PGP SIGNATURE- Version: N/A iQCVAwUBOsFeUv+IdJuhyV9xAQE2XAP9FF93ew+6Ml5iZ1jWjcGrs+3zaXIeWef6 SytNtIfyJqmcnyWnMaxBTlChIvBO5A2HVnBkCydM5BjUXdW1eWsEynrd+U79Yc+e yVDGo30CK3lAkTLH3Fo6jR3YZe/TsIyr80WlDeqJiWvDmHTfqvo50jRiDq2h1OL/ LmI4YIQM0rQ= =Vwwp -END PGP SIGNATURE- ---(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] Re: Call for platforms
Tatsuo Ishii [EMAIL PROTECTED] writes: mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii If compiled with -O2 or -O2 -g, I got 10 tests FAILED. misc test failed due to a backend crash. The SQL caused the crash was: select i, length(t), octet_length(t), oldstyle_length(i,t) from oldstyle_test; #0 ExecReplace (slot=0x1a4a7d0, tupleid=0x0, estate=0x1a4a708) at execMain.c:1408 1408resultRelationDesc = resultRelInfo-ri_RelationDesc; (gdb) where #0 ExecReplace (slot=0x1a4a7d0, tupleid=0x0, estate=0x1a4a708) at execMain.c:1408 #1 0x188471c in ExecutePlan (estate=0x0, plan=0x1a4a410, operation=CMD_SELECT, numberTuples=0, direction=27567836, destfunc=0x1a4adf8) at execMain.c:1127 #2 0x188471c in ExecutePlan (estate=0x0, plan=0x1a4a410, operation=CMD_SELECT, numberTuples=0, direction=27567836, destfunc=0x1a4adf8) at execMain.c:1127 #3 0x18838b8 in ExecutorRun (queryDesc=0x1a4a7d0, estate=0x1a4a708, feature=27567784, count=0) at execMain.c:233 I think you've got a badly broken compiler there. There's no way that ExecReplace should be entered for a SELECT. The backtrace is wrong on its face anyway --- ExecutePlan does not call itself. What gcc version does that platform have? regards, tom lane ---(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] Re: Call for platforms
I think you've got a badly broken compiler there. There's no way that ExecReplace should be entered for a SELECT. The backtrace is wrong on its face anyway --- ExecutePlan does not call itself. Yes, I have suspected that. What gcc version does that platform have? gcc version egcs-2.90.25 980302 (egcs-1.0.2 prerelease) -- Tatsuo Ishii ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Call for platforms
Tatsuo Ishii [EMAIL PROTECTED] writes: What gcc version does that platform have? gcc version egcs-2.90.25 980302 (egcs-1.0.2 prerelease) Can you try a known-stable gcc version? 2.95.2 say? regards, tom lane ---(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] Re: Call for platforms
Tatsuo Ishii [EMAIL PROTECTED] writes: What gcc version does that platform have? gcc version egcs-2.90.25 980302 (egcs-1.0.2 prerelease) Can you try a known-stable gcc version? 2.95.2 say? I don't have time right know. Will do maybe for 7.1.1 or 7.2.. -- Tatsuo Ishii ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Call for platforms
Suddenly I obtain access to ULTRIX black 4.3 1 RISC Uh ... what kind of processor is that? Offhand I don't see any indication that any of the entries in s_lock.h are supposed to work for Ultrix. As mentioned earlier, Ultrix on RISC means that it is a MIPS processor. DEC implemented OSF-1 for their Alpha processors. I suspect that some one of the implementations in s_lock.h was intended to be usable on Ultrix, and we've somehow dropped the declarations needed to make it go. You might want to pull down an old tarball (6.3 or before) and look at how it compiles the s_lock support on Ultrix. Any hints for Alexander on how to do it *if* it is a MIPS processor? - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: Call for platforms
The list of unreported or "in progress" platforms has gotten much shorter. If anyone can help on the remaining problems, we'll be able to move closer to release status, which is A Good Thing (tm) ;) btw, if we get most of these qualified, we will be on around 30 platforms - Thomas Unreported or problem platforms: Linux 2.0.x MIPS 7.0 2000-04-13, Tatsuo Ishii Tatsuo's machine has died. Anyone else with a Cobalt? mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii Any luck with RC1? NetBSD m68k7.0 2000-04-10, Henry B. Hotz NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo We need some NetBSD folks to speak up! Also, there are several flavors of OpenBSD which are not represented in our list, but which probably are already running PostgreSQL. Anyone? QNX 4.25 x86 7.0 2000-04-01, Dr. Andreas Kardos Does QNX get demoted to the "unsupported list"? It is known to have problems with 7.1, right? Solaris x867.0 2000-04-12, Marc Fournier scrappy, did you work through the tests yet? Ultrix MIPS7.1 2001-??-??, Alexander Klimov Any possibilities here? And here are the up-to-date platforms; thanks for the reports: AIX 4.3.3 RS6000 7.1 2001-03-21, Gilles Darold BeOS 5.0.3 x86 7.1 2000-12-18, Cyril Velter BSDI 4.01 x86 7.1 2001-03-19, Bruce Momjian Compaq Tru64 4.0g Alpha 7.1 2001-03-19, Brent Verner FreeBSD 4.3 x867.1 2001-03-19, Vince Vielhaber HPUX PA-RISC 7.1 2001-03-19, 10.20 Tom Lane, 11.00 Giles Lean IRIX 6.5.11 MIPS 7.1 2001-03-22, Robert Bruccoleri Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick Linux 2.2.x armv4l 7.1 2001-03-22, Mark Knox Linux 2.2.18 PPC750 7.1 2001-03-19, Tom Lane Linux 2.2.x S/390 7.1 2000-11-17, Neale Ferguson Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart MacOS X Darwin PPC 7.1 2000-12-11, Peter Bierman NetBSD 1.5 alpha 7.1 2001-03-22, Giles Lean NetBSD 1.5E arm32 7.1 2001-03-21, Patrick Welche NetBSD 1.5S x867.1 2001-03-21, Patrick Welche OpenBSD 2.8 x867.1 2001-03-22, Brandon Palmer SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie SCO UnixWare 7.1.1 x86 7.1 2001-03-19, Larry Rosenman Solaris 2.7 Sparc 7.1 2001-03-22, Marc Fournier SunOS 4.1.4 Sparc 7.1 2001-03-23, Tatsuo Ishii Windows/Win32 x86 7.1 2001-03-26, Magnus Hagander (clients only) WinNT/Cygwin x86 7.1 2001-03-16, Jason Tishler ---(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] Re: Call for platforms
Thomas Lockhart writes: SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie Where did you see this? I don't find it in the archives or in Vince's database. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Call for platforms
SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie Where did you see this? I don't find it in the archives or in Vince's database. In FAQ_SCO. I was looking to try to figure out what the differences were between the SCO products :) - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Call for platforms
Since the SCO UDK works on both UnixWare and OpenServer, I think we are pretty safe. Also, there was a post to -HACKERS about the accept bug and we changed the workaround to include OSR5. I'd leave it until disproved. I don't have a OSR5 installation to check it with, however. LER Original Message On 3/26/01, 12:05:55 PM, Thomas Lockhart [EMAIL PROTECTED] wrote regarding Re: [HACKERS] Re: Call for platforms: SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie Where did you see this? I don't find it in the archives or in Vince's database. In FAQ_SCO. I was looking to try to figure out what the differences were between the SCO products :) - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(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] Re: Call for platforms
Thomas Lockhart [EMAIL PROTECTED] writes: Linux 2.2.18 PPC750 7.1 2001-03-19, Tom Lane "PPC750"? What's that? "PPC G3" might be more likely to mean something to onlookers ... regards, tom lane ---(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] Re: Call for platforms
Thomas Lockhart [EMAIL PROTECTED] writes: As mentioned earlier, Ultrix on RISC means that it is a MIPS processor. I suspect that some one of the implementations in s_lock.h was intended to be usable on Ultrix, and we've somehow dropped the declarations needed to make it go. You might want to pull down an old tarball (6.3 or before) and look at how it compiles the s_lock support on Ultrix. Any hints for Alexander on how to do it *if* it is a MIPS processor? Not sure. The only info I see in s_lock.h is in the "SGI" section: * This stuff may be supplemented in the future with Masato Kataoka's MIPS-II * assembly from his NECEWS SVR4 port, but we probably ought to retain this * for the R3000 chips out there. That name doesn't ring a bell with me --- anyone remember what code is being referred to here, or where we might find Masato Kataoka? MIPS-II code may or may not be compatible with Alexander's machine anyway, but it's the only starting point I see. Anyway, the last CVS update to port/ultrix.h that appears to have come from someone actually using Ultrix was rev 1.2 on 7-May-97, which predates the very existence of s_lock.h as a separate file. So I'd definitely advise Alexander to find a tarball from that era and look at how Ultrix was handled then. I dunno if we even have tarballs from that far back on-line ... I suppose another possibility is a date-based pull from the CVS server. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Call for platforms
Thomas Lockhart writes: SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie Where did you see this? I don't find it in the archives or in Vince's database. In FAQ_SCO. I was looking to try to figure out what the differences were between the SCO products :) I wouldn't necessarily count something dated Oct 9, 2000. That was half a year ago, and even two months before beta. And the message doesn't actually say it worked. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(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] Re: Call for platforms
"PPC750"? What's that? "PPC G3" might be more likely to mean something to onlookers ... Actually "G3" means nothing outside of Apple afaict. The 750 series is a follow-on to the 60x series, and there is a 7xxx series also. From my pov, using an accepted label, rather than a marketing (re)label, better indicates *what* this actually can run on. I'm not sure that I have it labeled correctly yet, but "G3" is not a step in the right direction. As we both found, it is difficult to wade through Apple's own docs to decipher which processor is actually built into the system. Should I put "Mac G3" in the comment section? - Thomas ---(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] Re: Call for platforms
SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie Where did you see this? I don't find it in the archives or in Vince's database. In FAQ_SCO. I was looking to try to figure out what the differences were between the SCO products :) I wouldn't necessarily count something dated Oct 9, 2000. That was half a year ago, and even two months before beta. And the message doesn't actually say it worked. ?? I can see I was thrown off by the "last updated:" line near the top of the file. It actually comes from a CVS commit, not from an explicit update of the info in the file. Very bad :( - Thomas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Call for platforms
I would. LER -- Larry Rosenman http://www.lerctr.org/~ler/ Phone: +1 972 414 9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 US Original Message On 3/26/01, 2:36:19 PM, Thomas Lockhart [EMAIL PROTECTED] wrote regarding Re: [HACKERS] Re: Call for platforms: "PPC750"? What's that? "PPC G3" might be more likely to mean something to onlookers ... Actually "G3" means nothing outside of Apple afaict. The 750 series is a follow-on to the 60x series, and there is a 7xxx series also. From my pov, using an accepted label, rather than a marketing (re)label, better indicates *what* this actually can run on. I'm not sure that I have it labeled correctly yet, but "G3" is not a step in the right direction. As we both found, it is difficult to wade through Apple's own docs to decipher which processor is actually built into the system. Should I put "Mac G3" in the comment section? - Thomas ---(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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Call for platforms
Karl DeBisschop [EMAIL PROTECTED] writes:
In my tests on sparc/7 my compile died at line 3088 of
postgresql-7.1beta6/src/interfaces/python/pgmodule.c:
./pgmodule.c:3088: parse error before `init_pg'
That's line 3137 of today's (22Mar) snapshot, which reads:
/* Initialization function for the module */
DL_EXPORT(void)
init_pg(void)
{
What version of Python are you using? In Python 1.5, I find this
in Python.h:
#ifndef DL_EXPORT /* declarations for DLL import/export */
#define DL_EXPORT(RTYPE) RTYPE
#endif
which should make the above work.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Call for platforms
Thomas Lockhart wrote: Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick Linux 2.2.x armv4l 7.1 2001-03-22, Mark Knox Linux 2.2.18 PPC750 7.1 2001-03-19, Tom Lane Linux 2.2.x S/390 7.1 2000-11-17, Neale Ferguson Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart Did you get the message from Trond about Linux 2.4 x86? I can also verify all tests passed on a RedHat Public Beta installation with kernel 2.4. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Call for platforms
Lamar Owen [EMAIL PROTECTED] writes: Thomas Lockhart wrote: Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick Linux 2.2.x armv4l 7.1 2001-03-22, Mark Knox Linux 2.2.18 PPC750 7.1 2001-03-19, Tom Lane Linux 2.2.x S/390 7.1 2000-11-17, Neale Ferguson Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart Did you get the message from Trond about Linux 2.4 x86? I can also verify all tests passed on a RedHat Public Beta installation with kernel 2.4. I haven't put those in the list yet... I'll wait until we release a product, and test it on that. -- Trond Eivind Glomsrd Red Hat, Inc. ---(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] Re: Call for platforms
Trond Eivind Glomsrd wrote: Lamar Owen [EMAIL PROTECTED] writes: Did you get the message from Trond about Linux 2.4 x86? I can also verify all tests passed on a RedHat Public Beta installation with kernel 2.4. I haven't put those in the list yet... I'll wait until we release a product, and test it on that. Ah. Ok. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: Call for platforms
NetBSD m68k7.0 2000-04-10, Henry B. Hotz I no longer have a 68k machine that's fast enough to reasonably test PG on. I have a IIcx that sometimes serves as a router, but I'm using some second-generation powermac's mostly now. (You still have that Centris in your closet Tom?) Oof. With its giant 250MB hard disk. I'm not likely to ever get that going ;) I *did* just get MacOS X this weekend though and if I get it working on my work G4 maybe I could give it a try there. It will require at least the second Darwin beta release to work. - Thomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Call for platforms
I know that Sourceforge has been adding all sorts of machines to their compile farm. Maybe it would be worthwhile taking a look if they have platforms we don't? Regards and best wishes, Justin Clift Thomas Lockhart wrote: The non-test-and-set case should work again in current CVS, and I'd appreciate it if Alexander would verify that. But as far as getting some test-and-set support for MIPS goes, it looks like the only way is for someone to sit down with a MIPS assembly manual. I haven't got one, nor access to a machine to test on... That is not already available from the Irix support code? - Thomas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---(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] Re: Call for platforms
On Tue, Mar 27, 2001 at 12:01:24PM +1000, Justin Clift allegedly wrote: I know that Sourceforge has been adding all sorts of machines to their compile farm. Maybe it would be worthwhile taking a look if they have platforms we don't? Regards and best wishes, Justin Clift Compaq also still hands out free test accounts on Digital servers running Linux, Tru64 and FreeBSD... I think it's called the Testdrive program. Cheers, Mathijs -- It's not that perl programmers are idiots, it's that the language rewards idiotic behavior in a way that no other language or tool has ever done. Erik Naggum ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Regression test on FBSD 3.3 4.2, IRIX 6.5 (was Re: [HACKERS] Re: Call for platforms)
On Mon, Mar 26, 2001 at 07:09:38PM -0500, Tom Lane allegedly wrote:
Thomas Lockhart [EMAIL PROTECTED] writes:
That is not already available from the Irix support code?
What we have for IRIX is
#if defined(__sgi)
/*
* SGI IRIX 5
* slock_t is defined as a unsigned long. We use the standard SGI
* mutex API.
*
* The following comment is left for historical reasons, but is probably
* not a good idea since the mutex ABI is supported.
*
* This stuff may be supplemented in the future with Masato Kataoka's MIPS-II
* assembly from his NECEWS SVR4 port, but we probably ought to retain this
* for the R3000 chips out there.
*/
#include "mutex.h"
#define TAS(lock) (test_and_set(lock,1))
#define S_UNLOCK(lock)(test_then_and(lock,0))
#define S_INIT_LOCK(lock) (test_then_and(lock,0))
#define S_LOCK_FREE(lock) (test_then_add(lock,0) == 0)
#endif /* __sgi */
Doesn't look to me like it's likely to work on anything but IRIX ...
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
I just tried to compile 7.1RC1 on my IRIX 6.5 box using gcc 2.95.2.
Appearently gcc chokes on some assembly in src/backend/storage/buffer/s_lock.c
(tas_dummy on line 235 to be precise).
Here's the offending code:
#if defined(__mips__)
static void
tas_dummy()
{
__asm__ _volatile__(
"\
.global tas \n\
tas:\n\
.frame $sp, 0, $31 \n\
ll $14, 0($4) \n\
or $15, $14, 1 \n\
sc $15, 0($4) \n\
beq $15, 0, fail\n\
bne $14, 0, fail\n\
li $2, 0 \n\
.livereg 0x2000FF0E,0x0FFF \n\
j $31 \n\
fail: \n\
li $2, 1 \n\
j $31 \n\
");
}
Notice the single underscore before volatile. I just checked the CVS
version of s_lock.c and this is still not fixed. Fixing this causes
as (the SGI version, not GNU as) to choke on the '.global tas' statement.
s_lock.c: At top level:
s_lock.c:234: warning: `tas_dummy' defined but not used
as: Error: /var/tmp/ccoUdrOb.s, line 421: undefined assembler operation: .global
.global tas
gmake[4]: *** [s_lock.o] Error 1
Commenting out the .global statements does produce a binary, but it can't
complete the regression test due to other problems.
IpcSemaphoreCreate: semctl(id=0, 0, SETALL, ...) failed: Bad address
I'll see if I can come up with a solution for the .global and the
semaphore problem. I'll check wether pgsql 7.0 does run on this box too.
One wonders how Robert Bruccoleri did get 7.1RC1 to work properly. I'll
check the archive for clues.
On my FreeBSD 4.2 box 7.1RC1 runs flawlessly. I've also tested the CVS
version a few days ago on a 4.1.1 box without any problems.
FreeBSD 3.3 however does have some problems.
*** ./expected/float8-small-is-zero.out Fri Mar 31 07:30:31 2000
--- ./results/float8.out Tue Mar 27 02:28:07 2001
***
*** 214,220
SET f1 = FLOAT8_TBL.f1 * '-1'
WHERE FLOAT8_TBL.f1 '0.0';
SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
! ERROR: Bad float8 input format -- overflow
SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
ERROR: pow() result is out of range
SELECT '' AS bad, ln(f.f1) from FLOAT8_TBL f where f.f1 = '0.0' ;
--- 214,220
SET f1 = FLOAT8_TBL.f1 * '-1'
WHERE FLOAT8_TBL.f1 '0.0';
SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
! ERROR: floating point exception! The last floating point operation either exceeded
legal ranges or was a divide by zero
SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
ERROR: pow() result is out of range
SELECT '' AS bad, ln(f.f1) from FLOAT8_TBL f where f.f1 = '0.0' ;
Some geometry tests also fail. I'll check those tomorrow, erm, today. The
same goes for 7.1RC1 on Solaris 8 (Intel and Sparc).
Cheers,
Mathijs
--
It's not that perl programmers are idiots, it's that the language
rewards idiotic behavior in a way that no other language or tool has
ever done.
Erik Naggum
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Call for platforms
At 7:53 PM -0500 3/26/01, Tom Lane wrote: Thomas Lockhart [EMAIL PROTECTED] writes: "PPC750"? What's that? "PPC G3" might be more likely to mean something to onlookers ... Actually "G3" means nothing outside of Apple afaict. The 750 series is a follow-on to the 60x series, and there is a 7xxx series also. From my pov, using an accepted label, rather than a marketing (re)label, better indicates *what* this actually can run on. I'm not sure that I have it labeled correctly yet, but "G3" is not a step in the right direction. I found an apparently current "PowerPC CPU Summary" at http://e-www.motorola.com/webapp/sps/technology/tech_tutorial.jsp?catId=M943030621280 If accurate, the chip in this PowerBook is *not* a 750, since that tops out at 400 MHz. Apple offered this model in 400 and 500 MHz speeds, which makes it either a 7400 or 7410 chip ... Should I put "Mac G3" in the comment section? Yes, if you won't put it where it should be ;-). I'm still of the opinion that "G3" will mean something to a vastly larger population than "750" or "7400" would. The latter are "marketing relabels" too you know; Motorola's internal designation would probably be something else entirely. A "Me Too" from the peanut gallery. There are probably 1000x as many users that will recognize that they have a PowerPC G3 than will know they have a PPC750 or PPC7400. -pmb ---(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: Regression test on FBSD 3.3 4.2, IRIX 6.5 (was Re: [HACKERS] Re: Call for platforms)
Mathijs Brands [EMAIL PROTECTED] writes: Notice the single underscore before volatile. That's definitely wrong --- fixed. Fixing this causes as (the SGI version, not GNU as) to choke on the '.global tas' statement. s_lock.c: At top level: s_lock.c:234: warning: `tas_dummy' defined but not used as: Error: /var/tmp/ccoUdrOb.s, line 421: undefined assembler operation: .global .global tas gmake[4]: *** [s_lock.o] Error 1 Perhaps it should be ".globl"? That's another common spelling. Do you know whether anyone uses the GNU assembler on this platform, or is it always SGI's? I'm wondering if we need two versions of the assembly code ... I had missed the fact that s_lock.c contains some MIPS code. Anyone have any idea what versions of the MIPS series this code runs on? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: Call for platforms
Thomas Lockhart [EMAIL PROTECTED] writes: NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo Fetching the latest source kit now -- hope to have regression tests run and a report back to you within a day or two. We need some NetBSD folks to speak up! I've once again got a VAX that should be able to run PostgreSQL on NetBSD/vax, so I hope to be able to help revitalize that port soon... -tih -- The basic difference is this: hackers build things, crackers break them. ---(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] Re: Call for platforms
"Mark Knox" [EMAIL PROTECTED] writes: On 25 Mar 2001, at 16:07, Tom Lane wrote: Does that database have any user-created relations in it, or is it just a virgin database? Totally virgin. I created it just for that select you wanted. Okay. Would you create a couple of random tables in it and do the select again? I want to see what ctid looks like in a user-created table. I suspect it might be an alignment problem Sort of. I am suspicious that sizeof(ItemPointerData) is returning 8 rather than 6 as one might expect. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: Call for platforms
Hi all. Suddenly I obtain access to ULTRIX black 4.3 1 RISC I don't shure is it supported, but I see /src/include/port/ultrix4.h file so my guess is `yes, at least was'. I got last version from CVS and try configure gmake it results in gcc -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -c xlog.c -o xlog.o In file included from xlog.c:36: ../../../../src/include/storage/s_lock.h:88: warning: type defaults to `int' in declaration of `slock_t' ../../../../src/include/storage/s_lock.h:88: parse error before `*' ../../../../src/include/storage/s_lock.h:91: warning: type defaults to `int' in declaration of `slock_t' ../../../../src/include/storage/s_lock.h:91: parse error before `*' gmake[4]: *** [xlog.o] Error 1 grep of .h files shows that slock_t usualy defined in /src/include/port/*.h, but it is not defined in ultrix4.h and I can't find it in system includes. Regards, ASK ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Call for platforms
Tom Lane [EMAIL PROTECTED] writes: Alexander Klimov [EMAIL PROTECTED] writes: Suddenly I obtain access to ULTRIX black 4.3 1 RISC Uh ... what kind of processor is that? Offhand I don't see any indication that any of the entries in s_lock.h are supposed to work for Ultrix. The RISC/Ultrix machines ran (older) MIPS chips. Ultrix also ran (amazingly slowly) on the VAX architecture. [Fond memories of my first sysadmin job...] -Doug ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Call for platforms
Alexander Klimov [EMAIL PROTECTED] writes: Suddenly I obtain access to ULTRIX black 4.3 1 RISC Uh ... what kind of processor is that? Offhand I don't see any indication that any of the entries in s_lock.h are supposed to work for Ultrix. On closer look I notice that the putative support for machines without a TEST_AND_SET implementation got broken by careless rearrangement of the declarations in s_lock.h :-(. I have repaired this, and if you update from CVS you should find that things compile. However, you don't really want to run without TEST_AND_SET support; it'll be dog-slow. Furthermore, the support for machines without TEST_AND_SET is fairly new. I doubt it existed when the Ultrix port was last reported to work. So the question above still stands. I suspect that some one of the implementations in s_lock.h was intended to be usable on Ultrix, and we've somehow dropped the declarations needed to make it go. You might want to pull down an old tarball (6.3 or before) and look at how it compiles the s_lock support on Ultrix. Please send in a patch if you find that one is necessary for s_lock support on Ultrix. regards, tom lane ---(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] Re: Call for platforms
The Hermit Hacker wrote:
On Thu, 22 Mar 2001, Thomas Lockhart wrote:
Solaris x867.0 2000-04-12, Marc Fournier
scrappy, do you still have this machine?
Doing tests on Solaris x86/7 right now, will report as soon as they are
done ...
Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut
I'll bet that someone already has Solaris covered. Report?
Will do up Sparc/7 also this morning ...
In my tests on sparc/7 my compile died at line 3088 of
postgresql-7.1beta6/src/interfaces/python/pgmodule.c:
./pgmodule.c:3088: parse error before `init_pg'
That's line 3137 of today's (22Mar) snapshot, which reads:
/* Initialization function for the module */
DL_EXPORT(void)
init_pg(void)
{
I'm not a C expert by any means, but I can't figure how that is valid.
Given my ignorance, I don't want to call it a bug. Plus we don't use the
python module in production, nor the sparc platform. But it seemed worth
pointing out.
--
Karl
---(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] Re: Call for platforms
"Mark Knox" [EMAIL PROTECTED] writes: Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox Compiled and tested 7.1beta6 tonight. All the regression tests passed except two - the usual minor differences in geometry (rounding on the final digit) and this rather troubling output from type_sanity. Most bizarre --- and definitely indicative of trouble. Would you send along the output of this query in that database: select p1.oid,attrelid,relname,attname,attlen,attalign,attbyval from pg_attribute p1, pg_class p2 where atttypid = 27 and p2.oid = attrelid order by 1; regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Call for platforms
Does that database have any user-created relations in it, or is it just a virgin database? It seems that the wrong attlen is being computed for ctid fields during bootstrap, but the regression test output (if it was complete) implies that the value inserted for user-created fields was OK. This doesn't make a lot of sense since it's the same code... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Call for platforms
-BEGIN PGP SIGNED MESSAGE- On 25 Mar 2001, at 15:02, Tom Lane wrote: (rounding on the final digit) and this rather troubling output from type_sanity. Most bizarre --- and definitely indicative of trouble. Would you send along the output of this query in that database: select p1.oid,attrelid,relname,attname,attlen,attalign,attbyval from pg_attribute p1, pg_class p2 where atttypid = 27 and p2.oid = attrelid order by 1; I was afraid of that ;) Here's the output: [PostgreSQL 7.1beta6 on armv4l-unknown-linux-gnuoldld, compiled by GCC 2.95.1] type \? for help on slash commands type \q to quit type \g or terminate with semicolon to execute query You are currently connected to the database: postgres postgres= select p1.oid,attrelid,relname,attname,attlen,attalign,attbyval from pg_attribute p1, pg_class p2 where atttypid = 27 and p2.oid = attrelid order by 1; oid|attrelid|relname |attname|attlen|attalign|attbyval - -++--+---+--++ 16401|1247|pg_type |ctid | 6|i |f 16415|1262|pg_database |ctid | 6|i |f 16439|1255|pg_proc |ctid | 6|i |f 16454|1260|pg_shadow |ctid | 6|i |f 16464|1261|pg_group |ctid | 6|i |f 16486|1249|pg_attribute |ctid | 6|i |f 16515|1259|pg_class |ctid | 6|i |f 16526|1215|pg_attrdef|ctid | 6|i |f 16537|1216|pg_relcheck |ctid | 6|i |f 16557|1219|pg_trigger|ctid | 6|i |f 16572| 16567|pg_inherits |ctid | 8|i |f 16593| 16579|pg_index |ctid | 8|i |f 16610| 16600|pg_statistic |ctid | 8|i |f 16635| 16617|pg_operator |ctid | 8|i |f 16646| 16642|pg_opclass|ctid | 8|i |f 16678| 16653|pg_am |ctid | 8|i |f 16691| 16685|pg_amop |ctid | 8|i |f 16873| 16867|pg_amproc |ctid | 8|i |f 16941| 16934|pg_language |ctid | 8|i |f 16953| 16948|pg_largeobject|ctid | 8|i |f 16970| 16960|pg_aggregate |ctid | 8|i |f 17038| 17033|pg_ipl|ctid | 8|i |f 17051| 17045|pg_inheritproc|ctid | 8|i |f 17067| 17058|pg_rewrite|ctid | 8|i |f 17079| 17074|pg_listener |ctid | 8|i |f 17090| 17086|pg_description|ctid | 8|i |f 17206| 17201|pg_toast_1215 |ctid | 8|i |f 17221| 17216|pg_toast_17086|ctid | 8|i |f 17236| 17231|pg_toast_1255 |ctid | 8|i |f 17251| 17246|pg_toast_1216 |ctid | 8|i |f 17266| 17261|pg_toast_17058|ctid | 8|i |f 17281| 17276|pg_toast_16600|ctid | 8|i |f 17301| 17291|pg_user |ctid | 8|i |f 17314| 17309|pg_rules |ctid | 8|i |f 17327| 17322|pg_views |ctid | 8|i |f 17342| 17335|pg_tables |ctid | 8|i |f 17355| 17350|pg_indexes|ctid | 8|i |f (37 rows) -BEGIN PGP SIGNATURE- Version: N/A iQCVAwUBOr5XA/+IdJuhyV9xAQGfOgP6ApV6ia44bxCo/KyIE20knn/1FTysECW9 Rq9mLDhpYKHYtTWz1cgGtxzCEiRAMN+ZuO7u5nydy6TB8dp8iCd9eLAro4GAzqYM aD9V9S3nK3YwV9RaKBWJqHXNPI5enp19YS74GxN0f9VIw/4PXlYVm2tQJLVWNGs+ lFfQnraYEZQ= =Cj2l -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Call for platforms
Tom Lane writes: and yet another run (and different results): = 1 of 76 tests failed, 1 failed test(s) ignored. = That's just ye olde random "random" failure ... Actually, this is one real failed test plus the "random" failure. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(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] Re: Call for platforms
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: = 1 of 76 tests failed, 1 failed test(s) ignored. = That's just ye olde random "random" failure ... Actually, this is one real failed test plus the "random" failure. (Checks code...) Hm, you're right. May I suggest that this is a rather confusing wording? Perhaps 1 of 76 tests failed, plus 1 failed test(s) ignored. would be less likely to mislead people. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Call for platforms
OpenBSD 2.8 x867.1 2001-03-22, Brandon. Palmer OBSD checks out for sparc and i386. We did need to make a change to the resultmap file to make the regression tests clean for the sparc. I have attached the diff. Also, on the sparc that i'm using (sparc4/110), make check takes 1950 seconds. Most of the time is spent in this test: parallel group (13 tests): float4 int2 int4 text name varchar oid boolean char float8 int8 bit numeric There is a long pause between 'bit' and 'numeric'. Same with on i386. Is this a problem that is local to obsd? Is it an expected delay? It works, but seems like a real perf problem. Anyway: Sparc 4/110, 64M, SCSI disk, OBSD 2.8 virgin == All 76 tests passed. == 1941.34s real 130.23s user93.77s system $ uname -a OpenBSD azreal 2.8 GENERIC#0 sparc P2 300, 96M, IDE Disk, OBSD 2.8 virgin == All 76 tests passed. == 262.67s real21.84s user13.56s system $ uname -a OpenBSD orion 2.8 GENERIC#0 i386 I can't get tcl/tk working to same my life, but that's not too important for a release, just a config pain in the rear for obsd I guess. - brandon b. palmer, [EMAIL PROTECTED] pgp: www.crimelabs.net/bpalmer.pgp5 *** resultmap.orig Fri Mar 23 12:34:56 2001 --- resultmap.new Fri Mar 23 12:19:47 2001 *** *** 5,11 float4/.*-qnx=float4-exp-three-digits float8/.*-bsdi=float8-small-is-zero float8/.*-freebsd=float8-small-is-zero ! float8/.*-openbsd=float8-small-is-zero float8/i.86-.*-netbsd=float8-small-is-zero float8/.*-qnx=float8-exp-three-digits float8/alpha.*-dec-osf.*:cc=float8-fp-exception --- 5,11 float4/.*-qnx=float4-exp-three-digits float8/.*-bsdi=float8-small-is-zero float8/.*-freebsd=float8-small-is-zero ! float8/i.86-.*-openbsd=float8-small-is-zero float8/i.86-.*-netbsd=float8-small-is-zero float8/.*-qnx=float8-exp-three-digits float8/alpha.*-dec-osf.*:cc=float8-fp-exception *** *** 14,20 geometry/.*-darwin=geometry-powerpc-darwin geometry/.*-freebsd=geometry-positive-zeros geometry/.*-freebsd4=geometry-positive-zeros-bsd ! geometry/.*-openbsd=geometry-positive-zeros-bsd geometry/.*-irix6=geometry-irix geometry/.*-netbsd=geometry-positive-zeros geometry/.*-sysv5uw7.*:cc=geometry-uw7-cc --- 14,21 geometry/.*-darwin=geometry-powerpc-darwin geometry/.*-freebsd=geometry-positive-zeros geometry/.*-freebsd4=geometry-positive-zeros-bsd ! geometry/i386-.*-openbsd=geometry-positive-zeros-bsd ! geometry/sparc-.*-openbsd=geometry-positive-zeros geometry/.*-irix6=geometry-irix geometry/.*-netbsd=geometry-positive-zeros geometry/.*-sysv5uw7.*:cc=geometry-uw7-cc ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Call for platforms
bpalmer [EMAIL PROTECTED] writes: seconds. Most of the time is spent in this test: parallel group (13 tests): float4 int2 int4 text name varchar oid boolean char float8 int8 bit numeric There is a long pause between 'bit' and 'numeric'. Same with on i386. Is this a problem that is local to obsd? Is it an expected delay? Yes, that's the expected behavior. The 'numeric' test runs considerably longer than most of the others. (It used to be even slower, but I made Jan trim it down ;-)) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: Call for platforms
NetBSD-1.5/i386 one spurious floating point test failure (mail sent to postgresql-bugs with details) NetBSD_1.5/alphaall tests passed NetBSD-1.4.2/i386 four tests fail Thanks! I'm not too worried about 1.4.2, but be sure to let us know what the problem was; it may help out someone else... - Thomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] Re: Call for platforms
Here is the current scorecard. We have a couple of new platforms reported (yeaaa!): NetBSD 2.8 alpha 7.1 2001-03-22, Giles Lean OpenBSD 2.8 x867.1 2001-03-22, B. Palmer (first name?) Any more OpenBSD architectures out there running PostgreSQL? Here are the remaining (unreported, or unnoted) platforms: IRIX 6.5.6f MIPS 6.5.3 2000-02-18, Kevin Wheatley Anyone running IRIX? It may be on the unsupported list for 7.1 :( Linux 2.2.x armv4l 7.0 2000-04-17, Mark Knox Linux 2.0.x MIPS 7.0 2000-04-13, Tatsuo Ishii mklinux PPC750 7.0 2000-04-13, Tatsuo Ishii Tatsuo, do you still have access to the MIPS box? NetBSD m68k7.0 2000-04-10, Henry B. Hotz NetBSD Sparc 7.0 2000-04-13, Tom I. Helbekkmo QNX 4.25 x86 7.0 2000-04-01, Dr. Andreas Kardos cvs shows that there were patches from Maurizio in February, and he said that ecpg worked for him. Bruce applied the patches, but I'm not certain that this was done on the 7.1 code tree? Bruce, do you recall anything? Solaris x867.0 2000-04-12, Marc Fournier scrappy, do you still have this machine? Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut I'll bet that someone already has Solaris covered. Report? SunOS 4.1.4 Sparc 7.0 2000-04-13, Tatsuo Ishii Tatsuo, I vaguely recall that you reported trouble recently. Is this worth continuing as a supported platform? Windows/Win32 x86 7.0 2000-04-02, Magnus Hagander (clients only) Anyone compiled for Win32 recently? And here are the up-to-date platforms; thanks for the reports: AIX 4.3.3 RS6000 7.1 2001-03-21, Gilles Darold BeOS 5.0.3 x86 7.1 2000-12-18, Cyril Velter BSDI 4.01 x86 7.1 2001-03-19, Bruce Momjian Compaq Tru64 5.0 Alpha 7.0 2000-04-11, Andrew McMurry FreeBSD 4.2 x867.1 2001-03-19, Vince Vielhaber HPUX 10.20 PA-RISC 7.1 2001-03-19, Tom Lane IBMS/390 7.1 2000-11-17, Neale Ferguson Linux 2.2.x Alpha 7.1 2001-01-23, Ryan Kirkpatrick Linux 2.2.16 x86 7.1 2001-03-19, Thomas Lockhart Linux 2.2.15 Sparc 7.1 2001-01-30, Ryan Kirkpatrick LinuxPPC G37.1 2001-03-19, Tom Lane NetBSD 1.5E arm32 7.1 2001-03-21, Patrick Welche NetBSD 1.5S x867.1 2001-03-21, Patrick Welche SCO OpenServer 5 x86 7.1 2001-03-13, Billy Allie SCO UnixWare 7.1.1 x86 7.1 2001-03-19, Larry Rosenman MacOS-X Darwin PowerPC 7.1 2000-12-11, Peter Bierman WinNT/Cygwin x86 7.1 2001-03-16, Jason Tishler ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: Call for platforms
On Thu, 22 Mar 2001, Thomas Lockhart wrote: Solaris x867.0 2000-04-12, Marc Fournier scrappy, do you still have this machine? Doing tests on Solaris x86/7 right now, will report as soon as they are done ... Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut I'll bet that someone already has Solaris covered. Report? Will do up Sparc/7 also this morning ... AIX 4.3.3 RS6000 7.1 2001-03-21, Gilles Darold BeOS 5.0.3 x86 7.1 2000-12-18, Cyril Velter BSDI 4.01 x86 7.1 2001-03-19, Bruce Momjian Compaq Tru64 5.0 Alpha 7.0 2000-04-11, Andrew McMurry FreeBSD 4.2 x867.1 2001-03-19, Vince Vielhaber FreeBSD 4.3-BETA is good to go also ... ---(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
[HACKERS] Re: Call for platforms
FreeBSD 4.2 x867.1 2001-03-19, Vince Vielhaber FreeBSD 4.3-BETA is good to go also ... Yeah, I'm not sure how to list that, or whether to bother. It is beta, 4.2 works fine (and nothing had to change for 4.3, right?) so maybe we just list it when 4.3 goes stable? Or is 4.3 sufficiently different that it would be good to list in the comments for the platform? - Thomas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Call for platforms
Solaris x86/7 results, for example, in geometry.out, show a difference of: 3,-3.06204718156754e-11 (expected) 3,-3.06204718035418e-11 (results) acceptable diviation? That sort of deviation is well within bounds, particularly for geometry tests which might have some transcendental math involved. Is Solaris-x86 ready to go then? - Thomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Call for platforms
4.3 is in RELEASE CANDIDATE right now. By the time we release, it should be -RELEASE or -STABLE. I'd include it as just 4.3. It will be the -RELEASE at the time we are. LER Original Message On 3/22/01, 8:50:26 AM, Thomas Lockhart [EMAIL PROTECTED] wrote regarding [HACKERS] Re: Call for platforms: FreeBSD 4.2 x867.1 2001-03-19, Vince Vielhaber FreeBSD 4.3-BETA is good to go also ... Yeah, I'm not sure how to list that, or whether to bother. It is beta, 4.2 works fine (and nothing had to change for 4.3, right?) so maybe we just list it when 4.3 goes stable? Or is 4.3 sufficiently different that it would be good to list in the comments for the platform? - Thomas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(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] Re: Call for platforms
On Thu, 22 Mar 2001, Thomas Lockhart wrote: Solaris x86/7 results, for example, in geometry.out, show a difference of: 3,-3.06204718156754e-11 (expected) 3,-3.06204718035418e-11 (results) acceptable diviation? That sort of deviation is well within bounds, particularly for geometry tests which might have some transcendental math involved. Is Solaris-x86 ready to go then? Nope, still working through some things ... the select_implicit test failed completely: dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress more results/select_implicit.out psql: connectDBStart() -- connect() failed: Connection refused Is the postmaster running locally and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'? I'm going to re-run the test(s) and see if its an isolated thing or not ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Call for platforms
On Thu, 22 Mar 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Nope, still working through some things ... the select_implicit test failed completely: dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress more results/select_implicit.out psql: connectDBStart() -- connect() failed: Connection refused Is the postmaster running locally and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'? I'm going to re-run the test(s) and see if its an isolated thing or not ... Transient overflow of the postmaster socket's accept queue, maybe? How big is SOMAXCONN on your box? Okay, for me, solaris has always been a nemesis as I can never find anything on this box :( But, looking through the header files, I find: /usr/include/sys/socket.h:#define SOMAXCONN 5 I reran the tests two more times since the above ... first time went through clean as could be, with the geometry test failing (forgot to update my expected/resultmaps file(s) in my compile tree), the second time failed *totally* different tests then the first run: dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress grep FAILED regression.out opr_sanity ... FAILED join ... FAILED aggregates ... FAILED arrays ... FAILED I ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Call for platforms
The Hermit Hacker [EMAIL PROTECTED] writes: Nope, still working through some things ... the select_implicit test failed completely: dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress more results/select_implicit.out psql: connectDBStart() -- connect() failed: Connection refused Is the postmaster running locally and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'? I'm going to re-run the test(s) and see if its an isolated thing or not ... Transient overflow of the postmaster socket's accept queue, maybe? How big is SOMAXCONN on your box? regards, tom lane ---(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] Re: Call for platforms
OpenBSD 2.8 x867.1 2001-03-22, B. Palmer (first name?) Though it does work, like FBSD, there are some changes that need to be made to the system. Need max proc / files changes and a kernel recompile with SEMMNI and SEMMNS changes. Anywhere special to note this? So more-or-less the *same* configuration as is required for FBSD? If so, I could note that in the comments part of the platform support table. I'm not sure if either one (OBSD, FBSD) is actually explicitly documented for PostgreSQL (I don't see a FAQ, and am not sure if there is something in the sgml docs). Does anyone know if and where these things are noted? - Thomas ---(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] Re: Call for platforms
On Thu, 22 Mar 2001, Thomas Lockhart wrote: OpenBSD 2.8 x867.1 2001-03-22, B. Palmer (first name?) Though it does work, like FBSD, there are some changes that need to be made to the system. Need max proc / files changes and a kernel recompile with SEMMNI and SEMMNS changes. Anywhere special to note this? So more-or-less the *same* configuration as is required for FBSD? If so, I could note that in the comments part of the platform support table. The kernel changes are the same, but OBSD needs the max proc, max open file settings changes (no reboot required). I'm not sure if either one (OBSD, FBSD) is actually explicitly documented for PostgreSQL (I don't see a FAQ, and am not sure if there is something in the sgml docs). Does anyone know if and where these things are noted? http://www.postgresql.org/devel-corner/docs/postgres/kernel-resources.html This is the closest thing to docs. kernel-resources for specific OSs. - b b. palmer, [EMAIL PROTECTED] pgp: www.crimelabs.net/bpalmer.pgp5 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Call for platforms
The Hermit Hacker [EMAIL PROTECTED] writes: the second time failed *totally* different tests then the first run: dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress grep FAILED regression.out opr_sanity ... FAILED join ... FAILED aggregates ... FAILED arrays ... FAILED These are parallel tests right? What's the failure diffs? regards, tom lane ---(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] Re: Call for platforms
The Hermit Hacker writes: Is Solaris-x86 ready to go then? Nope, still working through some things ... the select_implicit test failed completely: dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress more results/select_implicit.out psql: connectDBStart() -- connect() failed: Connection refused Is the postmaster running locally and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'? I'm going to re-run the test(s) and see if its an isolated thing or not ... Solaris is known to have trouble with Unix domain sockets. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Call for platforms
On Thu, 22 Mar 2001, Thomas Lockhart wrote: OpenBSD 2.8 x867.1 2001-03-22, B. Palmer (first name?) Though it does work, like FBSD, there are some changes that need to be made to the system. Need max proc / files changes and a kernel recompile with SEMMNI and SEMMNS changes. Anywhere special to note this? b. palmer, [EMAIL PROTECTED] pgp: www.crimelabs.net/bpalmer.pgp5 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Call for platforms
The Hermit Hacker writes: How much 'diviation' are we allowing for? Solaris x86/7 results, for example, in geometry.out, show a difference of: 1.53102359078377e-11,3 (expected) 1.53102359017709e-11,3 (results) or 3,-3.06204718156754e-11 (expected) 3,-3.06204718035418e-11 (results) acceptable diviation? Practically yes, technically not. Check if the geometry results match any of the other "expected" files so we can update the "resultmap". See http://www.postgresql.org/devel-corner/docs/postgres/regress-platform.html -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: Call for platforms
Thomas Lockhart writes: Here is the current scorecard. We have a couple of new platforms reported (yeaaa!): QNX 4.25 x86 7.0 2000-04-01, Dr. Andreas Kardos This one is getting a "no good", as of latest reports. There are some issues to be worked out in the dreaded spin lock area, which will probably not happen between now and next week. And here are the up-to-date platforms; thanks for the reports: IBMS/390 7.1 2000-11-17, Neale Ferguson ^^^ should be "Linux" LinuxPPC G37.1 2001-03-19, Tom Lane The kernel is called "Linux", the processor is called "PowerPC G3". But "PowerPC" is probably enough, given that we list "x86". Compare to... MacOS-X Darwin PowerPC 7.1 2000-12-11, Peter Bierman ...this. There's a space, no dash, before the "X". -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(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] Re: Call for platforms
Thomas Lockhart writes: OpenBSD 2.8 x867.1 2001-03-22, B. Palmer (first name?) Though it does work, like FBSD, there are some changes that need to be made to the system. Need max proc / files changes and a kernel recompile with SEMMNI and SEMMNS changes. Anywhere special to note this? So more-or-less the *same* configuration as is required for FBSD? If so, I could note that in the comments part of the platform support table. Quite a few platforms will need some tuning in that area before production use. This is all documented. I'm not sure if either one (OBSD, FBSD) is actually explicitly documented for PostgreSQL (I don't see a FAQ, and am not sure if there is something in the sgml docs). Does anyone know if and where these things are noted? - Thomas -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(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] Re: Call for platforms
NetBSD 2.8 alpha 7.1 2001-03-22, Giles Lean Correction: NetBSD-1.5/alpha. Right. That was a typo in transcribing my online copy of the sgml docs to the email. I was hoping no one caught it, and didn't bother sending a correction ;) - Thomas ---(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] Re: Call for platforms
On Thu, Mar 22, 2001 at 12:49:39PM -0500, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: These are parallel tests right? What's the failure diffs? same as last time: dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress more results/opr_sanity.out psql: connectDBStart() -- connect() failed: Connection refused Is the postmaster running locally and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'? See Peter's comment elsewhere that he doesn't think Solaris handles Unix socket connections very well. Try patching pg_regress to force unix_sockets=no. and yet another run (and different results): = 1 of 76 tests failed, 1 failed test(s) ignored. = That's just ye olde random "random" failure ... Funny, I get the more optimistic: == 75 of 76 tests passed, 1 failed test(s) ignored. == Different version? PostgreSQL 7.1RC1 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Call for platforms
NetBSD 2.8 alpha 7.1 2001-03-22, Giles Lean Correction: NetBSD-1.5/alpha. Ciao, Giles ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Call for platforms
On Thu, 22 Mar 2001, Patrick Welche wrote: On Thu, Mar 22, 2001 at 12:49:39PM -0500, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: These are parallel tests right? What's the failure diffs? same as last time: dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress more results/opr_sanity.out psql: connectDBStart() -- connect() failed: Connection refused Is the postmaster running locally and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'? See Peter's comment elsewhere that he doesn't think Solaris handles Unix socket connections very well. Try patching pg_regress to force unix_sockets=no. and yet another run (and different results): = 1 of 76 tests failed, 1 failed test(s) ignored. = That's just ye olde random "random" failure ... Funny, I get the more optimistic: == 75 of 76 tests passed, 1 failed test(s) ignored. == Different version? PostgreSQL 7.1RC1 7.1RC1 (the not released yet version) :) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Call for platforms
Thomas Lockhart writes: SCO OpenServer 5 x86... OK, I see that Billy Allie recently updated FAQ_SCO to indicate demonstrated (?) support for OpenServer. I will reflect that in the platform support info. The last FAQ_SCO update was by me, and it was rather the consequence of some implementational developments and not a good indicator of any actually working platform. (I do have access to a Unixware box, but that was already reported.) -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: Call for platforms
SCO OpenServer 5 x86... OK, I see that Billy Allie recently updated FAQ_SCO to indicate demonstrated (?) support for OpenServer. I will reflect that in the platform support info. - Thomas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
