Third call for platform testing

Thomas Lockhart <lockhart@fourpalms.org> writes:

HPUX Tom (anyone tested 11.0 or higher?)

I thought we had a success report from someone for HPUX 11.

BTW, I'm hoping to help Tatsuo look into the reported instability
on AIX 5L. I'm guessing it's some unportable assumption in the
new LWLock code about behavior of semaphores. If we're really
lucky this might also extend to the reported Cygwin problem...

regards, tom lane

HPUX Tom (anyone tested 11.0 or higher?)

I thought we had a success report from someone for HPUX 11.

Yup. I have it in my (uncommitted) sgml list, but have been cutting and
pasting from previous emails and forgot to update this one.

BTW, I'm hoping to help Tatsuo look into the reported instability
on AIX 5L. I'm guessing it's some unportable assumption in the
new LWLock code about behavior of semaphores. If we're really
lucky this might also extend to the reported Cygwin problem...

Great. Do we have other folks looking at cygwin too, or is it dead in
the water unless you come up with something?

- Thomas

-----Original Message-----
From: Thomas Lockhart [mailto:lockhart@fourpalms.org]
Sent: 07 December 2001 16:15
To: Hackers List; Bill Studenmund; tegge@repas-aeg.de; Mark
Knox; Neale.Ferguson@softwareAG-usa.com; prlw1@cam.ac.uk; Tatsuo Ishii
Subject: Third call for platform testing

We've got most platforms ironed out, with just a few left to
get a definitive report. It looks like we'll end up dropping
a few platforms for this release (the first time in several
years that the number of supported platforms decreased!).

Windows/native Magnus Hagander (clients only)
Any reports?

Compiled OK with a few warnings using M$ VC++ 6, Service Pack 5.

Randomly tested psql/libpq with 7.2b3 on Slackware Linux 8.0 - no problems
found.

NOTE: I'm not able to test libpq++ as I don't know C++ or have any apps to
compile/test it with - it compiled OK though :-).

Regards, Dave.

Thomas Lockhart writes:

QNX Bernd Tegge, Igor Kovalenko
Anyone tested 4.x with 7.2,
or are we stuck with QNX6 needing patches?

Please note that QNX 4 and QNX 6 are completely different operating
systems that happen to come from the same company. So you don't want to
have one entry for both of them.

--
Peter Eisentraut peter_e@gmx.net

...

Please note that QNX 4 and QNX 6 are completely different operating
systems that happen to come from the same company. So you don't want to
have one entry for both of them.

Oh, of course. Don't know why one would assume that they are versions of
the *same* OS ;)

From recent emails, it looks like QNX 4 should be listed as supported,
and QNX 6 could/should be listed as "supported with patches". Or should
the status for 6 be something different?

- Thomas

SunOS Tatsuo Ishii
Are we giving up on this one? Still relevant?

What should we do? The only remaining issue is a non-8-bit-clean
memcmp, which seems pretty easy to fix it.
--
Tatsuo Ishii

Dave Page wrote:

Windows/native Magnus Hagander (clients only)

Compiled OK with a few warnings using M$ VC++ 6, Service Pack 5.
Randomly tested psql/libpq with 7.2b3 on Slackware Linux 8.0 - no problems
found.

Great! Thanks for testing and reporting...

- Thomas

...

Please note that QNX 4 and QNX 6 are completely different operating
systems that happen to come from the same company. So you don't want to
have one entry for both of them.

Oh, of course. Don't know why one would assume that they are versions of
the *same* OS ;)

From recent emails, it looks like QNX 4 should be listed as supported,

and QNX 6 could/should be listed as "supported with patches". Or should
the status for 6 be something different?

That seems right to me.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

SunOS Tatsuo Ishii
Are we giving up on this one? Still relevant?

What should we do? The only remaining issue is a non-8-bit-clean
memcmp, which seems pretty easy to fix it.

Yes, seems we could go a few directions with SunOS:

Leave bit types broken on that platform, document it
Hard-code in a memcmp() in C for just that platform in varbit.c
Add configure test and real memcmp() function for bad platforms

Anyone want to vote on these? Personally, SunOS seems like the
granddaddy of ports and I would hate to see it leave, especially when we
are so close.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Build and test run sucessfully on Linux/390 and
Linux/PlayStation2 with low-order-digit diffs in
geometry.

Permaine

Build and test run sucessfully on Linux/390 and
Linux/PlayStation2 with low-order-digit diffs in
geometry.

Oooh, too cool. Thanks for the report! Could you post results (the
regression.out file etc) on the developer's web site? Especially for the
new platform: we probably need more details on how easy or hard it was
to get the new platform working...

- Thomas

Sure, I'll post the results. Actually, on S/390, there's no need
to change anything, but on the PS/2, the test-and-set code
doesn't work on that CPU, Tom Lane suggested a workaround -
undefine HAS_TEST_AND_SET and remove slock_t type
definition in the port include file. With those modifications,
both the build and tests work fine.

Permaine

----- Original Message -----
From: Thomas Lockhart <lockhart@fourpalms.org>
To: Permaine Cheung <pcheung@redhat.com>
Cc: <pgsql-hackers@postgresql.org>
Sent: Wednesday, December 12, 2001 5:38 PM
Subject: Re: Third call for platform testing

Build and test run sucessfully on Linux/390 and
Linux/PlayStation2 with low-order-digit diffs in
geometry.

Cool - Postgres on a PlayStation 2!!!

Chris

Sure, I'll post the results. Actually, on S/390, there's no need
to change anything, but on the PS/2, the test-and-set code
doesn't work on that CPU, Tom Lane suggested a workaround -
undefine HAS_TEST_AND_SET and remove slock_t type
definition in the port include file. With those modifications,
both the build and tests work fine.

OK, S/390 is easy.

For PS/2, how does the CPU identify itself? If you have to remove the
slock_t definition from the port include file then presumably it does
identify itself as one of the already supported CPUs (alpha, arm, ia64,
i386, mips, ppc, sparc, s390), right? Or does some other default setting
get used that you then #undef in that include file?

A few more details would probably let someone reproduce your result,
which would be enough to consider this as a supported platform. That is,
as long as you aren't running the only PlayStation 2 in the world with
Linux?? Heck, on second thought we'd consider it supported even so ;)

- Thomas

OK, S/390 is easy.

For PS/2, how does the CPU identify itself? If you have to remove the
slock_t definition from the port include file then presumably it does
identify itself as one of the already supported CPUs (alpha, arm, ia64,
i386, mips, ppc, sparc, s390), right? Or does some other default setting
get used that you then #undef in that include file?

I specified --template=linux. :)

A few more details would probably let someone reproduce your result,
which would be enough to consider this as a supported platform. That is,
as long as you aren't running the only PlayStation 2 in the world with
Linux?? Heck, on second thought we'd consider it supported even so ;)

I'm trying to submit the report, however, I've been getting a
PostgreSQL query failure saying regresstests does not exist in
/usr/local/www/developer/regress/regress.php.

Permaine

On Thu, 13 Dec 2001, Permaine Cheung wrote:

OK, S/390 is easy.

For PS/2, how does the CPU identify itself? If you have to remove the
slock_t definition from the port include file then presumably it does
identify itself as one of the already supported CPUs (alpha, arm, ia64,
i386, mips, ppc, sparc, s390), right? Or does some other default setting
get used that you then #undef in that include file?

I specified --template=linux. :)

A few more details would probably let someone reproduce your result,
which would be enough to consider this as a supported platform. That is,
as long as you aren't running the only PlayStation 2 in the world with
Linux?? Heck, on second thought we'd consider it supported even so ;)

I'm trying to submit the report, however, I've been getting a
PostgreSQL query failure saying regresstests does not exist in
/usr/local/www/developer/regress/regress.php.

Marc moved the database yesterday to another machine. The database
I use for mirroring, regression tests, the website, and a bunch of
other things has yet to be restored. I can't do it myself because
the other machine is no longer listening. So I'm just about 100%
out of business.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

For PS/2, how does the CPU identify itself? If you have to remove the
slock_t definition from the port include file then presumably it does
identify itself as one of the already supported CPUs (alpha, arm, ia64,
i386, mips, ppc, sparc, s390), right? Or does some other default setting
get used that you then #undef in that include file?

I specified --template=linux. :)

And it is an x86 CPU?

A few more details would probably let someone reproduce your result,
which would be enough to consider this as a supported platform. That is,
as long as you aren't running the only PlayStation 2 in the world with
Linux?? Heck, on second thought we'd consider it supported even so ;)

I'm trying to submit the report, however, I've been getting a
PostgreSQL query failure saying regresstests does not exist in
/usr/local/www/developer/regress/regress.php.

Yeah, something apparently broke on the server. Vince?

In the meantime, you can post those results to this mailing list (or to
the -ports mailing list).

- Thomas

...

Marc moved the database yesterday to another machine. The database
I use for mirroring, regression tests, the website, and a bunch of
other things has yet to be restored. I can't do it myself because
the other machine is no longer listening. So I'm just about 100%
out of business.

Whoops. Marc, can we help with something here?

- Thomas

And it is an x86 CPU?

It's a mips CPU.

Permaine