Thread: Call for porting reports
I'd like to collect info on the platforms we are supporting for v7.0.
I've listed below all of the platforms which have been supported in
the past and any new platforms such as QNX which have a new "sponsor".
Since this is a major release, it is probably the right time to cull
our list of platforms which just aren't in use anymore, even though
afaik there have been no changes in the last couple of full releases
which would have broken their support. So, if we don't get a report,
the platform will go to the "maybe supported" category.
Here is the list of platforms for which I need reports. Note that in
some cases you might have already reported on them, but either the
report came *with* patches, so I'm not certain that the current tree
has them applied and you have tested them, or perhaps I just got
confused and missed a good report. In either case, I need confirmation
again. Something which says:
o tested on the current tree or a recent beta
o installed and ran with no problems, or
o for a very few platforms, installed and ran with minimal or known
patches
o regress tests pass or are understood with no fundamental problems
Here are the platforms, along with the name of a recent caretaker:
AIX (Andreas Zeugswetter)
BSDI (Bruce - hey, where is your report! :)
DGUX (Brian Gallew lost his platform a while ago; this one may be
unsupported)
Digital Unix (Pedro et al. Similar patches to Linux-alpha?)
FreeBSD (Tatsuo and scrappy)
HPUX (Tom Lane; Stan still here or anyone else want to pitch in?)
IRIX (Kevin Wheatley recently reported on v6.5.3)
Linux-alpha (this one still needs the "Ryan" or "Uncle George"
patches?)
Linux-arm41 (Mark Knox recently did v6.5.3)
Linux-x86 (Covered by Lamar Owens and Thomas for RH; should we report
other distros too? How about libc vs glibc? I've tested libc, but
should we bother listing it?)
Linux-sparc (Tom Szybist, but no report since v6.4 so unsupported?)
Linux-ppc (Tatsuo already reported. Thanks!)
MacOS (Still nothing? Does OS-X or whatever have a chance?)
MkLinux-ppc (Tatsuo, but this merged with Linux-ppc, right? So
obsolete?)
NetBSD-arm32 (Andrew McMurry)
NetBSD-x86 (Patrick Welche already reported. Thanks!)
NetBSD-m68k (Mr. Mutsuki Nakajima via Tatsuo, but nothing since v6.4)
NetBSD-ns32k (Jon Buller, but nothing since v6.4)
NetBSD-sparc (Tom I Helbekkmo, v6.4)
NetBSD-vax (Tom I Helbekkmo, but nothing since v6.3. Unsupported?)
QNX (Andreas Kardos. Recent reports, but we have recent changes to
config.guess)
SCO OpenServer (Andrew Merrill)
SCO UnixWare 7 (Billy Allie needs one more patch?)
Solaris-x86 (scrappy doing it this weekend?)
Solaris-sparc (Tom Szybist and Frank Ridderbusch for v6.4)
SunOS 4.1.4 (Tatsuo; obsolete platform?)
SVR4-mips (Frank Ridderbusch, no int8, v6.4. Obsolete?)
SVR4-m88k (Nothing for two years. Needed spinlock code. Obsolete?)
Ultrix (No reports for either MIPS or VAX for two years. Dead and
gone?)
WIN9x (Magnus Hagander, v6.4, client side only. Still good?)
WINNT (Daniel Horak already reported for v7.0. Thanks!)
Any others? I'd like to get finalized within a week or so. If you
think you will be able to test but can't right away, send some mail so
we know someone might be working on it. I always hate to drop a
platform from the list, but if no one is using it or testing it we'll
move 'em to the unsupported list by release day :(
TIA
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> I'd like to collect info on the platforms we are supporting for v7.0.
> [snip]
> HPUX (Tom Lane; Stan still here or anyone else want to pitch in?)
I have checked recent sources on HPUX 9.03 and 10.20 using gcc,
but am trying to find time to check it with the vendor cc before
filing a report. I also have an un-dealt-with report of changes
needed for HPUX 11.* ... anyone using that?
regards, tom lane
On Sun, Apr 02, 2000 at 12:25:15AM +0000, Thomas Lockhart wrote: > Linux-x86 (Covered by Lamar Owens and Thomas for RH; should we report > other distros too? How about libc vs glibc? I've tested libc, but Yes, of course we should list other distros. Debian shouldn't be a problem as there are several on this list. Or else we should only list Linux without naming a distor at all. > should we bother listing it?) I don't think so. No distro is still libc based AFAIK. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL!
> Yes, of course we should list other distros. Debian shouldn't be a problem
> as there are several on this list.
> Or else we should only list Linux without naming a distor at all.
Right. Sorry, I wasn't clear; at the moment I don't mention which
distro was actually tested. I know Oliver has Debian covered (and I'm
running Mandrake on a couple of systems so I can test that -- it
passes btw ;) and that we will hear from someone when there is
trouble.
I'll keep listing it generically, until we get a report of problems
with any distro and then we can reopen the issue.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> > WIN9x (Magnus Hagander, v6.4, client side only. Still good?)
> That should probably read Win32 - it's WinNT/2000 too. And WinNT client
> libraries compiled using Cygwin will not work on "native NT".
> I've compiled and tested 7.0beta3, looks good (client side only).
>
> > WINNT (Daniel Horak already reported for v7.0. Thanks!)
> That shuold probably be called WinNT/Cygwin or something, since it's not
> really Win32/NT.
> Oh, and has it been tested on Windows 2000? If not, I can probably throw
> together a test sometime this week.
Thanks for the info. I'll update the entries. I can't remember if
Daniel was testing on W2K or on something else. Daniel?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> Or else we should only list Linux without naming a distor at all. > > > should we bother listing it?) > > I don't think so. No distro is still libc based AFAIK. true, however not all people are running the most up to date slackware (7.0) and afaik versions before 7 were not glibc2 based. perhaps 4 was, but i think it was short lived compared to the 3.x series. Jeff MacDonald jeff@pgsql.com
Thomas Lockhart writes: > I'd like to collect info on the platforms we are supporting for v7.0. I am now reproduceably getting this failure in the timestamp test. I have never seen it before today: *** expected/timestamp.out Sun Apr 2 14:15:29 2000 --- results/timestamp.out Sun Apr 2 18:01:21 2000 *************** *** 13,25 **** SELECT (timestamp 'today' = (timestamp 'tomorrow' - interval '1 day')) as "True"; True ------ ! t (1 row) SELECT (timestamp 'tomorrow' = (timestamp 'yesterday' + interval '2 days')) as "True"; True ------ ! t (1 row) SELECT (timestamp 'current' = 'now') as "True"; --- 13,25 ---- SELECT (timestamp 'today' = (timestamp 'tomorrow' - interval '1 day')) as "True"; True ------ ! f (1 row) SELECT (timestamp 'tomorrow' = (timestamp 'yesterday' + interval '2 days')) as "True"; True ------ ! f (1 row) SELECT (timestamp 'current' = 'now') as "True"; *************** *** 81,87 **** SELECT count(*) AS one FROM TIMESTAMP_TBL WHERE d1 = timestamp 'today' + interval '1 day'; one ----- ! 1 (1 row) SELECT count(*) AS one FROM TIMESTAMP_TBL WHERE d1 = timestamp 'today' - interval '1 day'; --- 81,87 ---- SELECT count(*) AS one FROM TIMESTAMP_TBL WHERE d1 = timestamp 'today' + interval '1 day'; one ----- ! 0 (1 row) SELECT count(*) AS one FROM TIMESTAMP_TBL WHERE d1 = timestamp 'today' - interval '1 day'; ---------------------- The catch is that this *always* happens in the (parallel) regression tests but not if I run the file through psql by hand. Gives me a warm feeling ... :( Furthermore, PostgreSQL doesn't compile with gcc 2.8.1 (never has). I get a fatal signal if backend/utils/adt/float.c is compiled with -O2 or higher. The offending line is in function float64 dpow(float64 arg1, float64 arg2) *result = (float64data) pow(tmp1, tmp2); Certainly a compiler bug, does anyone have a suggestion how this should be handled? Is gcc 2.8.1 in wide-spread use? -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
> I am now reproduceably getting this failure in the timestamp test. I have
> never seen it before today:...
> The catch is that this *always* happens in the (parallel) regression tests
> but not if I run the file through psql by hand. Gives me a warm feeling
> ... :(
Almost certainly due to daylight savings time in PST8PDT (it happened
today). As the doctor says, you'll feel better in a couple of days :)
This happens every year (actually, twice a year). But it would be
wrong to not test the yesterday/today/tomorrow feature at all...
> Furthermore, PostgreSQL doesn't compile with gcc 2.8.1 (never has). I get
> a fatal signal if backend/utils/adt/float.c is compiled with -O2 or
> higher. The offending line is in function
> float64 dpow(float64 arg1, float64 arg2)
> *result = (float64data) pow(tmp1, tmp2);
> Certainly a compiler bug, does anyone have a suggestion how this should be
> handled? Is gcc 2.8.1 in wide-spread use?
I'm guessing that 2.8.x is not in wide-spread use. What platform are
you on? You could force -O0 for your platform, even just for that
directory, as long as you don't disable it for other platform/compiler
combinations.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Peter Eisentraut <peter_e@gmx.net> writes:
> I am now reproduceably getting this failure in the timestamp test. I have
> never seen it before today:
Is today DST changeover where you live?
The time-related tests have always failed near DST boundaries; the
queries you mention effectively assume that the difference between
successive midnights is exactly 24 hours, which is wrong for DST days.
> The catch is that this *always* happens in the (parallel) regression tests
> but not if I run the file through psql by hand. Gives me a warm feeling
> ... :(
Ah. The parallel tests set up the postmaster's timezone to be PST8PDT.
Today is DST changeover in that zone, even if it isn't where you live.
> Furthermore, PostgreSQL doesn't compile with gcc 2.8.1 (never has). I get
> a fatal signal if backend/utils/adt/float.c is compiled with -O2 or
> higher. The offending line is in function
> float64 dpow(float64 arg1, float64 arg2)
> *result = (float64data) pow(tmp1, tmp2);
> Certainly a compiler bug, does anyone have a suggestion how this should be
> handled? Is gcc 2.8.1 in wide-spread use?
Write it off as a broken compiler. Compiler segfaults on valid code are
not our problem. (As far as I know, the 2.8 series of gcc releases were
never robust enough for production use. Try 2.95.2 instead.)
regards, tom lane
On Sun, 2 Apr 2000, Thomas Lockhart wrote: > I'd like to collect info on the platforms we are supporting for v7.0. > I've listed below all of the platforms which have been supported in > the past and any new platforms such as QNX which have a new "sponsor". .... > Linux-alpha (this one still needs the "Ryan" or "Uncle George" > patches?) I have the patches nearly up to date. I am doing a final check on beta-3 right now. I should have patches ready and my web page updated in by Wedesday. Sorry about the delay in response, but I have been busy with school. :(More details to come. --------------------------------------------------------------------------- | "For to me to live is Christ, and to die is gain." | | --- Philippians 1:21 (KJV) | --------------------------------------------------------------------------- | Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ | ---------------------------------------------------------------------------
> > > WIN9x (Magnus Hagander, v6.4, client side only. Still good?)
> > That should probably read Win32 - it's WinNT/2000 too. And
> WinNT client
> > libraries compiled using Cygwin will not work on "native NT".
> > I've compiled and tested 7.0beta3, looks good (client side only).
> >
> > > WINNT (Daniel Horak already reported for v7.0. Thanks!)
> > That shuold probably be called WinNT/Cygwin or something,
It is possible to call it WinNT/Cygwin because there can be a port using
UWIN or even a "native" port.
> since it's not
> > really Win32/NT.
> > Oh, and has it been tested on Windows 2000? If not, I can
> probably throw
> > together a test sometime this week.
>
> Thanks for the info. I'll update the entries. I can't remember if
> Daniel was testing on W2K or on something else. Daniel?
I have not tested pgsql on W2K, but I am testing Win95 and it looks
promissing - it is possible to run initdb, start postmaster and only a newly
created backend dies (with segfault) after it receives a connection from a
client. And such an error could be solved (I hope ;-). It has no problems
with the IPC stuff.
Dan
Postgresql-8.0.0rc1 hardware: HP Dual PPro os: Linux Slackware 10.0.0 kernel: 2.6.9-ac16 SMP gcc: 3.3.4 configure: ./configure --prefix=/usr/local/pgsql --with-tcl --with-perl --with-x --enable-syslog --with-openssl --with-pgport=5432 --with-odbc --enable-thread-safety 8.0.0beta4 was installed make check failed the first time with a "cannot set locale" error. I installed 8.0.0rc1, make check was successful ======================All 96 tests passed. ====================== Thanks for a great database, David Walker