Обсуждение: Last call?
Hi. I believe we are still shooting for a Nov 1 release, though without
reports of successful regression tests on more platforms I'm not sure we
can do that. I know that at least some of those listed below are the
active development platforms for some contributors, so those are
probably covered but I need confirmation. So, if you have a platform you
have tested or plan to have tested in the next few days please speak up.
Now. Or at least Soon :)
Here are the ones on the "currently supported" list (let me know if you
have something running on another platform. Any Ultrix people out there
still?):
_ AIX 4.1.x-4.2
_ BSDi
_ FreeBSD 2.2.x-3.x
_ NetBSD 1.3
_ NetBSD 1.3 NS32532
_ NetBSD 1.3 Sparc
_ NetBSD 1.3 VAX
_ DGUX 5.4R4.11 m88k
_ HPUX 10.20
_ IRIX 6.x
_ Digital 4.0
_ linux 2.0.x Alpha
x linux 2.0.x x86
_ linux 2.0.x Sparc
x mklinux PPC750
_ SCO
_ Solaris x86
_ Solaris 2.5.1-2.6 x86
_ SunOS 4.1.4 Sparc
x SVR4 MIPS
_ SVR4 4.4 m88k
x Unixware x86
x Windows NT
The porting info goes into the Admin Guide in the docs. I plan to freeze
that one last, a few days before release to give Bruce et al a chance to
polish the installation and release notes.
The other docs will need to freeze earlier to give me a chance to
generate hardcopy for v6.4. So the freeze schedule will be (again
assuming a Nov 1 release, and I'm probably not giving myself enough
time):
Oct 26: freeze Programmer's Guide and Developer's Guide
Oct 27: freeze User's Guide and reference pages
Oct 28: freeze Admin Guide
Oct 29-30: finish hardcopy, generate html
I will be out of town Oct 31-Nov 1, so need to finish a day or two
early. As it is, I should have frozen some docs by now to get this stuff
done.
So, if you have anything else to contribute or update for docs, SEND IT
IN NOW. Or at least let me know it is coming soon. Or it will have to
wait for v6.5...
TIA
- Tom
> Here are the ones on the "currently supported" list (let me know if you > have something running on another platform. Any Ultrix people out there > still?): Change:> _ BSDi to> _ BSDI 3.x and 4.0 Also, the Windows NT item is of much interest. Can we report this as working, and have a binary of 6.4 built at the time of the 6.4 release, November 1? (I am CC'ing the NT person.) -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> Change:
> > _ BSDi
> to
> > _ BSDI 3.x and 4.0
The underscores meant that I don't know if the platform has been
regression tested yet. Exes meant I did. I was assuming that you had
already done BSDI (isn't that you're development platform?) and was
hoping to get a report from you saying to put an "x" for that one.
So the only platforms I've marked as being confirmed are NT, Unixware,
SVR4, mklinux, and linux. But I know there are others which are already
working, I'm just not certain exactly which ones...
- Tom
Hi Tom and all I did not know what the '_' and 'x' meant the first time, as I recall the one for 'Linux ix86' had an '_', or unknown, I can do this for you, should I grab the Bata2 or the latest snapshot? On Sun, 25 Oct 1998, Thomas G. Lockhart wrote: > > Change: > > > _ BSDi > > to > > > _ BSDI 3.x and 4.0 > > The underscores meant that I don't know if the platform has been > regression tested yet. Exes meant I did. I was assuming that you had > already done BSDI (isn't that you're development platform?) and was > hoping to get a report from you saying to put an "x" for that one. > > So the only platforms I've marked as being confirmed are NT, Unixware, > SVR4, mklinux, and linux. But I know there are others which are already > working, I'm just not certain exactly which ones... > > - Tom > Terry Mackintosh <terry@terrym.com> http://www.terrym.com sysadmin/owner Please! No MIME encoded or HTML mail, unless needed. Proudly powered by R H Linux 4.2, Apache 1.3, PHP 3, PostgreSQL 6.3 ------------------------------------------------------------------- Success Is A Choice ... book by Rick Patino, get it, read it!
"Thomas G. Lockhart" wrote: >So the only platforms I've marked as being confirmed are NT, Unixware, >SVR4, mklinux, and linux. Tom, can you distinguish between linux with libc5 and with glibc (aka libc6)? -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID32B8FAA1 ======================================== "If ye then be risen with Christ, seek those things which are above, where Christ sitteth on the right hand of God. Set your affection on things above, not on things on the earth." Colossians 3:1,2
> I did not know what the '_' and 'x' meant the first time, as I recall
> the one for 'Linux ix86' had an '_', or unknown
Thanks Terry, but I've already got that one done (it's my development
platform). The Linux Alpha and Sparc need testing, which is probably
what you remember seeing...
- Tom
> can you distinguish between linux with libc5 and with glibc?
Yes, if necessary. I'm running glibc at work (with the RH 6.3.2 rpms)
and libc5 at home (with v6.4beta). I don't expect there to be any
significant differences; are you aware of any?
Also, I'm planning on doing a clean install of v6.4beta on my glibc
machine, so can verify it then.
Or are you just saying that we should mention both explicitly so that
people can know that it would work on their machine for sure?
- Tom
> > Change: > > > _ BSDi > > to > > > _ BSDI 3.x and 4.0 > > The underscores meant that I don't know if the platform has been > regression tested yet. Exes meant I did. I was assuming that you had > already done BSDI (isn't that you're development platform?) and was > hoping to get a report from you saying to put an "x" for that one. > > So the only platforms I've marked as being confirmed are NT, Unixware, > SVR4, mklinux, and linux. But I know there are others which are already > working, I'm just not certain exactly which ones... Oh, sorry. Put an X for BSDI. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Here are the ones on the "currently supported" list (let me know if you have something running on another platform. AnyUltrix people out there still?): x NetBSD 1.3.2/i386 I'm running on NetBSD 1.3.2/i386 and as of yesterday the regressions all passed. I'm trying to redo them every few days to make sure nothing creeps in so this should be a supported platform. Cheers, Brook
> x NetBSD 1.3.2/i386
> I'm running on NetBSD 1.3.2/i386 and as of yesterday the regressions
> all passed. I'm trying to redo them every few days to make sure
> nothing creeps in so this should be a supported platform.
This is exactly what makes it a supported platform :)
- Tom
> > 'Linux ix86' had an '_', or unknown
> Thanks Terry, but I've already got that one done
But Oliver was asking about glibc2 vs libc5. Do you happen to have a
glibc machine (RH 5.x?) available? If so we could use a direct report of
success since I'm still running RH4.2/libc5 for development...
- Tom
Hi Tom Nope, RH4.2/libc5, same as you. Still waiting for the dust to settle on the glibc thing:) On Sun, 25 Oct 1998, Thomas G. Lockhart wrote: > > > 'Linux ix86' had an '_', or unknown > > Thanks Terry, but I've already got that one done > > But Oliver was asking about glibc2 vs libc5. Do you happen to have a > glibc machine (RH 5.x?) available? If so we could use a direct report of > success since I'm still running RH4.2/libc5 for development... > > - Tom Terry Mackintosh <terry@terrym.com> http://www.terrym.com sysadmin/owner Please! No MIME encoded or HTML mail, unless needed. Proudly powered by R H Linux 4.2, Apache 1.3, PHP 3, PostgreSQL 6.3 ------------------------------------------------------------------- Success Is A Choice ... book by Rick Patino, get it, read it!
I compiled it on RH 5.1... no problems. Taral > -----Original Message----- > From: owner-pgsql-hackers@postgreSQL.org > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Thomas G. > Lockhart > Sent: Sunday, October 25, 1998 12:08 PM > To: Terry Mackintosh; PostgreSQL-development > Subject: Re: [HACKERS] Re: [DOCS] Last call? > > > > > 'Linux ix86' had an '_', or unknown > > Thanks Terry, but I've already got that one done > > But Oliver was asking about glibc2 vs libc5. Do you happen to have a > glibc machine (RH 5.x?) available? If so we could use a direct report of > success since I'm still running RH4.2/libc5 for development... > > - Tom >
I'm sure Oliver runs a libc6 system. He is one of the debian core developers. -Egon On Sun, 25 Oct 1998, Thomas G. Lockhart wrote: > > > 'Linux ix86' had an '_', or unknown > > Thanks Terry, but I've already got that one done > > But Oliver was asking about glibc2 vs libc5. Do you happen to have a > glibc machine (RH 5.x?) available? If so we could use a direct report of > success since I'm still running RH4.2/libc5 for development... > > - Tom > >
I cannot believe, RH4.2 isn't a glibc2 system. -Egon On Sun, 25 Oct 1998, Terry Mackintosh wrote: > Hi Tom > > Nope, RH4.2/libc5, same as you. > Still waiting for the dust to settle on the glibc thing:) > > On Sun, 25 Oct 1998, Thomas G. Lockhart wrote: > > > > > 'Linux ix86' had an '_', or unknown > > > Thanks Terry, but I've already got that one done > > > > But Oliver was asking about glibc2 vs libc5. Do you happen to have a > > glibc machine (RH 5.x?) available? If so we could use a direct report of > > success since I'm still running RH4.2/libc5 for development... > > > > - Tom > > > Terry Mackintosh <terry@terrym.com> http://www.terrym.com > sysadmin/owner Please! No MIME encoded or HTML mail, unless needed. > > Proudly powered by R H Linux 4.2, Apache 1.3, PHP 3, PostgreSQL 6.3 > ------------------------------------------------------------------- > Success Is A Choice ... book by Rick Patino, get it, read it! > > >
I just gave today's (Oct 25) snapshot a try on Sparc Linux.
Looks good except datetime. I'm getting failures due to this type
of thing:
regression=> SELECT ('today'::datetime );
?column?
----------------------------
Sun Oct 25 00:00:00 1998 EDT
(1 row)
regression=> SELECT ('tomorrow'::datetime - '1 day'::timespan);
?column?
----------------------------
Sun Oct 25 01:00:00 1998 EDT
(1 row)
I *think* this may because we're not too far into EST yet.
Sound good?
My machine is Kernel is 2.0.29. Libc 5.3.12.
Tom Szybist
szybist@boxhill.com
In message <3632A932.7FEB1733@alumni.caltech.edu>, "Thomas G. Lockhart" writes:
> Hi. I believe we are still shooting for a Nov 1 release, though without
> reports of successful regression tests on more platforms I'm not sure we
> can do that. I know that at least some of those listed below are the
> active development platforms for some contributors, so those are
> probably covered but I need confirmation. So, if you have a platform you
> have tested or plan to have tested in the next few days please speak up.
> Now. Or at least Soon :)
>
> Here are the ones on the "currently supported" list (let me know if you
> have something running on another platform. Any Ultrix people out there
> still?):
>
> _ AIX 4.1.x-4.2
> _ BSDi
> _ FreeBSD 2.2.x-3.x
> _ NetBSD 1.3
> _ NetBSD 1.3 NS32532
> _ NetBSD 1.3 Sparc
> _ NetBSD 1.3 VAX
> _ DGUX 5.4R4.11 m88k
> _ HPUX 10.20
> _ IRIX 6.x
> _ Digital 4.0
> _ linux 2.0.x Alpha
> x linux 2.0.x x86
> _ linux 2.0.x Sparc
> x mklinux PPC750
> _ SCO
> _ Solaris x86
> _ Solaris 2.5.1-2.6 x86
> _ SunOS 4.1.4 Sparc
> x SVR4 MIPS
> _ SVR4 4.4 m88k
> x Unixware x86
> x Windows NT
>
>
> The porting info goes into the Admin Guide in the docs. I plan to freeze
> that one last, a few days before release to give Bruce et al a chance to
> polish the installation and release notes.
>
> The other docs will need to freeze earlier to give me a chance to
> generate hardcopy for v6.4. So the freeze schedule will be (again
> assuming a Nov 1 release, and I'm probably not giving myself enough
> time):
>
> Oct 26: freeze Programmer's Guide and Developer's Guide
> Oct 27: freeze User's Guide and reference pages
> Oct 28: freeze Admin Guide
> Oct 29-30: finish hardcopy, generate html
>
> I will be out of town Oct 31-Nov 1, so need to finish a day or two
> early. As it is, I should have frozen some docs by now to get this stuff
> done.
>
> So, if you have anything else to contribute or update for docs, SEND IT
> IN NOW. Or at least let me know it is coming soon. Or it will have to
> wait for v6.5...
>
> TIA
>
> - Tom
>
"Thomas G. Lockhart" wrote: >> can you distinguish between linux with libc5 and with glibc? > >Yes, if necessary. I'm runningglibc at work (with the RH 6.3.2 rpms) >and libc5 at home (with v6.4beta). I don't expect there to be any >significantdifferences; are you aware of any? No; there are minor textual differences in the math overflow messages and, last time I tried, the geometry tests had differences of around 10 ^ -12. >... >Or are you just saying that we should mention both explicitly so that >people can know that it would work on theirmachine for sure? Precisely. The difference is such a major one that linux-libc5 and linux-glibc should be regarded nearly as two different systems. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID32B8FAA1 ======================================== "If ye then be risen with Christ, seek those things which are above, where Christ sitteth on the right hand of God. Set your affection on things above, not on things on the earth." Colossians 3:1,2
"Thomas A. Szybist" wrote:
>
> I just gave today's (Oct 25) snapshot a try on Sparc Linux.
> Looks good except datetime. I'm getting failures due to this type
> of thing:
>
> regression=> SELECT ('today'::datetime );
> ?column?
> ----------------------------
> Sun Oct 25 00:00:00 1998 EDT
> (1 row)
>
> regression=> SELECT ('tomorrow'::datetime - '1 day'::timespan);
> ?column?
> ----------------------------
> Sun Oct 25 01:00:00 1998 EDT
> (1 row)
>
>
> I *think* this may because we're not too far into EST yet.
> Sound good?
>
This is not a failure. The date 24 hours (1 day) before 'Mon Oct 26 00:00:00 1998 EST' is 'Sun Oct 25 01:00:00 1998
EDT'. You would think it should be 'Sun Oct 25 00:00:00 1998 EST', but thanks to Daylight Savings Time that datetime
doesnot exist :-)
--
____ | Billy G. Allie | Domain....: Bill.Allie@mug.org
| /| | 7436 Hartwell | Compuserve: 76337,2061
|-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com
|/ |LLIE | (313) 582-1540 |
> I just gave today's (Oct 25) snapshot a try on Sparc Linux.
> Looks good except datetime.
OK, picky picky. Run the test tomorrow instead. And I'll mark you down
as having tested and passed today :)
- Tom
> I compiled it on RH 5.1... no problems.
OK. Just to be unambiguous, I'd prefer a statement that includes "...
and passed all regression tests". It did, right?
- Tom
> The difference is such a major one that linux-libc5 and linux-glibc
> should be regarded nearly as two different systems.
Sure. Well, I'm planning on building v6.4beta at work anyway, and will
try the regression tests. So we should have a firm confirmation for v6.4
then. Though it sounds like Oliver has tried something fairly recently?
Aside from the math rounding problems (I even see slight differences on
my libc5 machine when using the egcs compiler) I _really_ don't expect
to see a true failure.
- Tom
Err.. umm... Updated 10/25 17:05 CST. The following tests fail on my system (RH 5.1 - glibc): int2, int4: Different error format (Math result not representable is now Numerical result out of range) float8: Weird... one query that was supposed to fail returned a bunch of NaNs, another failed when it wasn't supposed to with an out of range error. geometry: The results are only approximately right... but only in the first sig. figure :( datetime: CDT/CST thing sanity_check: **backend aborts** random: Fails because it returns a value outside the 80-120 range misc: Rows out of order I'm afraid this one can't go as 'supported'. Sorry. Taral > -----Original Message----- > From: owner-pgsql-hackers@postgreSQL.org > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Thomas G. > Lockhart > Sent: Sunday, October 25, 1998 4:58 PM > To: Taral > Cc: Terry Mackintosh; PostgreSQL-development > Subject: Re: [HACKERS] Re: [DOCS] Last call? > > > > I compiled it on RH 5.1... no problems. > > OK. Just to be unambiguous, I'd prefer a statement that includes "... > and passed all regression tests". It did, right? > > - Tom >
> sanity_check: **backend aborts** > random: Fails because it returns a value outside the 80-120 range > misc: Rows out of order All passed when I reinitialized the db. Taral
> > sanity_check: **backend aborts**
> > random: Fails because it returns a value outside the 80-120 range
> > misc: Rows out of order
> All passed when I reinitialized the db.
OK, good.
btw, the random test will still occasionally fail, since a two or three
sigma result will have values outside the 80-120 range. But rerunning
should get something within range, usually.
- Tom
> > > sanity_check: **backend aborts** > > > random: Fails because it returns a value outside the 80-120 range > > > misc: Rows out of order Note that int2,int4,float8,geometry are still failing... Why is geometry sooo far out? Taral
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
> _ HPUX 10.20
You can put down an X for both HPUX 9.03 and 10.20.
I discovered a number of minor problems when I tried to compile with
HP's cc instead of gcc like I usually do. I just committed fixes for
those.
I am still getting a discrepancy in the "rules" regression test,
namely a difference in the order in which tuples are returned:
*** expected/rules.out Fri Oct 2 12:28:01 1998
--- results/rules.out Sun Oct 25 19:31:42 1998
***************
*** 315,322 **** pname |sysname ------+------- bm |pluto
- jwieck|orion jwieck|notjw (3 rows) QUERY: delete from rtest_system where sysname = 'orion';
--- 315,322 ---- pname |sysname ------+------- bm |pluto jwieck|notjw
+ jwieck|orion (3 rows) QUERY: delete from rtest_system where sysname = 'orion';
----------------------
This happens on all four permutations of HPUX version and compiler.
Are other people really seeing the tuple order given in the "expected"
file?
regards, tom lane
In message <3633AC8B.756C31BB@alumni.caltech.edu>, "Thomas G. Lockhart" writes: > > I just gave today's (Oct 25) snapshot a try on Sparc Linux. > > Looks good except datetime. > > OK, picky picky. Run the test tomorrow instead. And I'll mark you down > as having tested and passed today :) > > - Tom Do I still get full credit ?:) I noticed your list did not have Solaris / Sparc. I gave that a spin as well. Aside from datetime, my results confirm the expected diffs supplied. Tom Szybist szybist@boxhill.com
> > _ DGUX 5.4R4.11 m88k
> Dude, I just lost my DGUX box, so I will no longer be able to verify
> DGUX ports. Sorry.
OK, thanks for letting me know. You still running Postgres? Especially
on other exotic platforms? Always fishing for new ones... :)
Anyone else out there running DGUX who wants to continue verifying this
port? I'm pretty sure we are OK for this release, but we don't want to
get too stale.
- Tom
I still need reports on:
> _ AIX 4.1.x-4.2
> _ FreeBSD 2.2.x-3.x
> _ NetBSD 1.3 NS32532
> _ NetBSD 1.3 Sparc
> _ NetBSD 1.3 VAX
> _ DGUX 5.4R4.11 (m88k or ? we need a new maintainer)
> _ IRIX 6.x (Andrew, are you available?)
> _ Digital 4.0
> _ linux 2.0.x Alpha
> _ SCO (Billy, can you confirm success now?)
> _ Solaris x86
> _ Solaris 2.5.1-2.6 Sparc
> _ SunOS 4.1.4 Sparc
> _ SVR4 4.4 m88k (I have v6.3 "confirmed with patching". better now?)
> x Windows NT
Tatsuo, is your usual stable of machines available for reporting? It
would be nice to get confirmation with that big-endian/little-endian
mix.
How should I list WindowsNT? I have "mostly working, check web site for
patches" at the moment, but I don't know if we have more info available
now.
I would welcome confirming reports on other platforms too.
- Tom
On Mon, 26 Oct 1998, Thomas G. Lockhart wrote:
> I still need reports on:
>
> > _ linux 2.0.x Alpha
I have gotten it to compile successfully again (fixes to our old
friend S_LOCK) and I should have a patch out in a few days (big test {at
college} on Wedesday, so it will later in the week). Most of the
regression tests are working, except the datetime ones (no, sorry, can't
blame daylight savings this time, that is unless the year is all of a
sudden 2136. :( ). I doubt I will have that working by Nov 2, as I have
been trying for a few months with out success to find these bugs. I will
post the patch and more detail on the datetime problems by the end of this
week to the pgsql-{ports,hacker,patch} mailing lists. TTYAL.
----------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
----------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | rkirkpat@nag.cs.colorado.edu |
----------------------------------------------------------------------------
| http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
----------------------------------------------------------------------------
Tom Lane wrote:
> I am still getting a discrepancy in the "rules" regression test,
> namely a difference in the order in which tuples are returned:
>
> *** expected/rules.out Fri Oct 2 12:28:01 1998
> --- results/rules.out Sun Oct 25 19:31:42 1998
> ***************
> *** 315,322 ****
> pname |sysname
> ------+-------
> bm |pluto
> - jwieck|orion
> jwieck|notjw
> (3 rows)
>
> QUERY: delete from rtest_system where sysname = 'orion';
> --- 315,322 ----
> pname |sysname
> ------+-------
> bm |pluto
> jwieck|notjw
> + jwieck|orion
> (3 rows)
>
> QUERY: delete from rtest_system where sysname = 'orion';
>
> ----------------------
>
> This happens on all four permutations of HPUX version and compiler.
> Are other people really seeing the tuple order given in the "expected"
> file?
I think they should be in the order given in the expected
file.
The rows inserted into the rtest_admin table (really a table,
not a view) are:
pname|sysname
-----+-------
jw |orion
jw |notjw
bm |neptun
Then two updates are performed. The rules that are there
would add parsetrees as if these queries are given:
UPDATE rtest_admin SET sysname = 'pluto'
WHERE rtest_system.sysname = 'neptun'
AND rtest_admin.sysname = rtest_system.sysname;
UPDATE rtest_admin SET pname = 'jwieck'
WHERE rtest_person.pdesc = 'Jan Wieck'
AND rtest_admin.pname = rtest_person.pdesc;
These two queries will produce join plans. Since there are no
indices on any of the tables, they should produce tuples in
exactly the order they where entered into the table. An
UPDATE creates a new tuple, inserts it and outdates the
current by ctid.
In rtest_system and rtest_person there are only 1 row that
matches each of the given qualifications. So the question is
why on HPUX the order of tuples returned in the resulting
join plans differs from other OS's. The SELECT that produces
the wrong order above should result in a SeqScan, and that
must return the tuples in ctid order.
The first rule update on rtest_admin (fired at the UPDATE on
rtest_system.sysname) doesn't change the order of the tuples
(or did you omit this in your mail?). So why the hell does
the second? Updated rows always appear at the end of a
SeqScan in the order they where updated. There is no vacuum
between the updates, so the space from the outdated tuples
should not be reused here.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
jwieck@debis.com (Jan Wieck) writes:
> These two queries will produce join plans. Since there are no
> indices on any of the tables, they should produce tuples in
> exactly the order they where entered into the table.
I modified the rules.sql test to perform an EXPLAIN of the query
that is generating the unexpected result, and it says:
QUERY: explain update rtest_person set pname = 'jwieck' where pdesc = 'Jan Wieck';
NOTICE: QUERY PLAN:
Merge Join (cost=0.00 size=1 width=42) -> Seq Scan (cost=0.00 size=0 width=0) -> Sort (cost=0.00 size=0
width=0) -> Seq Scan on rtest_admin (cost=0.00 size=0 width=30) -> Seq Scan (cost=0.00 size=0 width=0)
-> Sort (cost=0.00 size=0 width=0) -> Seq Scan on rtest_person (cost=0.00 size=0 width=12)
NOTICE: QUERY PLAN:
Seq Scan on rtest_person (cost=0.00 size=0 width=18)
The thing that jumps out at me here is the "sort" step (which I assume
is on pname for rtest_admin and pdesc for rtest_person, those being the
fields to be joined). Since the prior state of rtest_admin is
QUERY: select * from rtest_admin;
pname|sysname
-----+-------
jw |orion
jw |notjw
bm |pluto
(3 rows)
the two rows that will be updated have equal sort keys and therefore the
sort could legally return them in either order. Does Postgres contain
its own sort algorithm for this kind of operation, or does it depend on
the system qsort? System library qsorts don't normally guarantee
stability for equal keys. It could be that we're looking at a byproduct
of some minor implementation difference between the qsorts on my machine
and yours. If that's it, though, I'm surprised that I'm the only one
reporting a difference in the test's output.
BTW, I get the same query plan if I EXPLAIN the query that you say the
rule should expand to,
UPDATE rtest_admin SET pname = 'jwieck' WHERE rtest_person.pdesc = 'Jan Wieck' AND
rtest_admin.pname= rtest_person.pdesc;
so there doesn't seem to be anything wrong with the rule rewriter...
regards, tom lane
On Mon, 26 Oct 1998, Thomas G. Lockhart wrote:
> I still need reports on:
>
> > _ AIX 4.1.x-4.2
Duane out there was going to do this one for us, assuming that he
still had access to that machine...
> > _ FreeBSD 2.2.x-3.x
Building now...
> > _ NetBSD 1.3 NS32532
> > _ NetBSD 1.3 Sparc
> > _ NetBSD 1.3 VAX
> > _ DGUX 5.4R4.11 (m88k or ? we need a new maintainer)
> > _ IRIX 6.x (Andrew, are you available?)
> > _ Digital 4.0
> > _ linux 2.0.x Alpha
> > _ SCO (Billy, can you confirm success now?)
> > _ Solaris x86
> > _ Solaris 2.5.1-2.6 Sparc
Will rebuild and regress test both the x86/Sparc platforms for 2.6
during the day tomorrow...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Sun, 25 Oct 1998, Thomas G. Lockhart wrote: > _ linux 2.0.x Alpha Neither 6.4B2 nor the oct26 snapshot compile on my RH 5.0 Alpha Linux (2.0.30) computer. I don't have much time to work on it, but I can provide the gmake.log and access to the machine if it would help. Doug ------------------------------------------------------------------------ My views are actually owned by a small, strange, orange man from the planet zikalikzutorabibian who can only communicate by making cryptic oblong symbols in warm food. If you have problems with my views, please take them up with him. ------------------------------------------------------------------------ For Hire: Will write code/manage networks for obscene amounts of money. ------------------------------------------------------------------------ Doug Babst - Owner | P.O. Box 103 | (402) 463-3426 - Voice TCG Computer Services | Hastings, NE 68901 | (402) 463-1754 - Fax http://www.tcgcs.com | http://www.babst.org/~dbabst/resume
>Tatsuo, is your usual stable of machines available for reporting? It
>would be nice to get confirmation with that big-endian/little-endian
>mix.
I have run the regression tests of Oct26 Snapshot on some platforms
and a cross platform testing on MkLinux and FreeBSD.
Here are results.
(1) regression tests on some platforms
LinuxPPC on PowerMac:o PowerBook 2400c (PPC 603e) running 2.1.24 kernel
Note that 2.1.24 kernel doesn't support PCMCIA cards, so we cannot use the network facility at all. sigh. (Unix
domainsockets are ok) On the other hand, 2.1.1xx kernels do support PCMCIA, unfortunately, these are broken in that
usingthe Unix domain sockets causes the system crash. Anyway, these are not PostgreSQL's problem, of course.
o regresion tests are almost good except the datetime test.
SELECT ('tomorrow'::datetime = ('yesterday'::datetime + '2 days'::timespan)) as "True"; --> shows 'false'
SELECT('current'::datetime = 'now'::datetime) as "True"; --> shows 'false' SELECT count(*) AS one FROM
DATETIME_TBLWHERE d1 = 'today'::datetime; --> no row selected They were ok on 6.3.2.
MkLinux on PowerMac:o PowerMac 7600 (PPC 750) running MkLinux DR3o Same failure of the datetime test as LinuxPPC
FreeBSD:o FreeBSD 2.2.6-RELEASEo datetime testing fails (seems same phenomenon as LinuxPPC)o int8 testing fails (is
thisnormal?)
Seems there's something wrong with datetime. Comment?
(2) cross platform testing
I have run the test with FreeBSD 2.2.7 and Mklinux. Seems they are
happy to talk to each other.
Please let me know If you need addional testings.
--
Tatsuo Ishii
t-ishii@sra.co.jp
Tom Lane wrote:
> I modified the rules.sql test to perform an EXPLAIN of the query
> that is generating the unexpected result, and it says:
>
> QUERY: explain update rtest_person set pname = 'jwieck' where pdesc = 'Jan Wieck';
> NOTICE: QUERY PLAN:
>
> Merge Join (cost=0.00 size=1 width=42)
> -> Seq Scan (cost=0.00 size=0 width=0)
> -> Sort (cost=0.00 size=0 width=0)
> -> Seq Scan on rtest_admin (cost=0.00 size=0 width=30)
> -> Seq Scan (cost=0.00 size=0 width=0)
> -> Sort (cost=0.00 size=0 width=0)
> -> Seq Scan on rtest_person (cost=0.00 size=0 width=12)
>
> NOTICE: QUERY PLAN:
>
> Seq Scan on rtest_person (cost=0.00 size=0 width=18)
Isn't it nice to have EXPLAIN doing the rewrite step?
> [...]
>
> the two rows that will be updated have equal sort keys and therefore the
> sort could legally return them in either order. Does Postgres contain
> its own sort algorithm for this kind of operation, or does it depend on
> the system qsort? System library qsorts don't normally guarantee
> stability for equal keys. It could be that we're looking at a byproduct
> of some minor implementation difference between the qsorts on my machine
> and yours. If that's it, though, I'm surprised that I'm the only one
> reporting a difference in the test's output.
Could be the reason. createfirstrun() in psort.c is using
qsort as a first try. Maybe we should add ORDER BY pname,
sysname to the queries to avoid it.
>
> BTW, I get the same query plan if I EXPLAIN the query that you say the
> rule should expand to,
>
> UPDATE rtest_admin SET pname = 'jwieck'
> WHERE rtest_person.pdesc = 'Jan Wieck'
> AND rtest_admin.pname = rtest_person.pdesc;
>
> so there doesn't seem to be anything wrong with the rule rewriter...
Sure. The parsetree generated by the rule system is exactly
that what the parser outputs for this query. I hope some
people understand my new documentation of the rule system.
Sometimes the lonesome rule-rider needs a partner too.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #
> LinuxPPC on PowerMac:
> o PowerBook 2400c (PPC 603e) running 2.1.24 kernel
> o regresion tests are almost good except the datetime test.
> They were ok on 6.3.2.
>
> MkLinux on PowerMac:
> o PowerMac 7600 (PPC 750) running MkLinux DR3
> o Same failure of the datetime test as LinuxPPC
>
> FreeBSD:
> o FreeBSD 2.2.6-RELEASE
> o datetime testing fails (seems same phenomenon as LinuxPPC)
> o int8 testing fails (is this normal?)
>
> Seems there's something wrong with datetime. Comment?
Yes. I have learned to never ask for regression testing reports near a
daylight savings time boundary. I assume Japan set the clock back an
hour last Sunday? The explicit tests for 'yesterday', 'today',
'tomorrow' combined with date arithmetic fail since there is an hour
offset across that boundary. In a day or two the tests will succeed.
I'm not sure why FreeBSD has trouble with int8. It of course requires
support from the compiler, and configure tries to test for it. You don't
use gcc? If not, then perhaps you could check into 64-bit integer
support on your compiler. If you do use gcc, perhaps the test is having
trouble finding the complete set of libraries. I used to have a problem
on my Linux box with that; the 64-bit int subtraction routine didn't
make it into libc, but was hidden in some machine-specific library way
down the tree.
Perhaps you and Marc can look into the FreeBSD int8 problem?
> (2) cross platform testing
> I have run the test with FreeBSD 2.2.7 and Mklinux. Seems they are
> happy to talk to each other.
This is all good. Thanks.
- Tom
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> o regresion tests are almost good except the datetime test.
> SELECT ('tomorrow'::datetime = ('yesterday'::datetime
> + '2 days'::timespan)) as "True"; --> shows 'false'
I assume you ran these tests during Monday (PST)? That's a symptom
of the daylight savings time transition issue that was just discussed
to death on pg-hackers. Not to worry --- it's just a shortcoming
of the datetime regression test, not a bug in Postgres.
> SELECT ('current'::datetime = 'now'::datetime)
> as "True"; --> shows 'false'
> SELECT count(*) AS one FROM DATETIME_TBL WHERE
> d1 = 'today'::datetime; --> no row selected
These two worry me more. They don't look like they should be
subject to the DST issue, and no one else reported seeing them
fail over the weekend. Thomas, any thoughts?
> FreeBSD:
> o int8 testing fails (is this normal?)
It is if the platform does not have a 64-bit integer data type.
If FreeBSD's compiler and C library do support a 64-bit int type,
then there is a problem that we ought to fix. Most likely,
configure doesn't know the name of the type to try, or isn't trying
the right format string for sprintf/sscanf of a long long int.
regards, tom lane
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
> Yes. I have learned to never ask for regression testing reports near a
> daylight savings time boundary. I assume Japan set the clock back an
> hour last Sunday?
Japan doesn't use DST last I heard, but it doesn't matter. The
regression tests are run with TZ=PST8PDT, so American DST boundaries are
the windows in which the datetime test will fail, anywhere in the world.
(Given correctly installed worldwide TZ info on the local system, of
course, but I suspect you can assume that most Unix systems will have
info about the American timezones...)
regards, tom lane
> Japan doesn't use DST last I heard, but it doesn't matter. The
> regression tests are run with TZ=PST8PDT, so American DST boundaries
> are the windows in which the datetime test will fail, anywhere in the
> world.
Oh. Right.
- Tom
jwieck@debis.com (Jan Wieck) writes:
> Tom Lane wrote:
>> the two rows that will be updated have equal sort keys and therefore the
>> sort could legally return them in either order. Does Postgres contain
>> its own sort algorithm for this kind of operation, or does it depend on
>> the system qsort? System library qsorts don't normally guarantee
>> stability for equal keys. It could be that we're looking at a byproduct
>> of some minor implementation difference between the qsorts on my machine
>> and yours. If that's it, though, I'm surprised that I'm the only one
>> reporting a difference in the test's output.
> Could be the reason. createfirstrun() in psort.c is using
> qsort as a first try. Maybe we should add ORDER BY pname,
> sysname to the queries to avoid it.
I think this is the answer then. Some poking around in HP's patch
documentation shows that they modified their version of qsort a while
back:
PHCO_6780:qsort performs very badly on sorted blocks of data- customer found that qsort on a file with 100,000randomly
sortedrecords took seconds, whereas a fileof 100,000 records containing large sorted blockstook over an hour to
sort.qsortneeded to pick an alternate pivot point whendetecting sorted or partially sorted data in orderto improve poor
performance.
So I guess it's not so surprising if HP's qsort has slightly different
behavior on equal-keyed data than everyone else's.
Does anyone object to modifying this regression test to sort the
tuples for display? It seems that only the one query needs to be
changed...
regards, tom lane
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
> _ NetBSD 1.3
We normally write NetBSD/i386 1.3 (or 1.3.2, the latest version).
> _ NetBSD 1.3 Sparc
I just ran the regression tests on NetBSD/sparc 1.3H, which is an
interim (current) version between 1.3.2 and 1.4. All tests pass
except float8, which generates the following extra error messages:
barsoom:tih> diff -c expected/float8-NetBSD.out results/float8.out
*** expected/float8-NetBSD.out Thu Oct 8 18:12:14 1998
--- results/float8.out Tue Oct 27 20:07:18 1998
***************
*** 213,219 ****
--- 213,221 ---- QUERY: INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e400'); ERROR: Bad float8 input format '-10e400' QUERY:
INSERTINTO FLOAT8_TBL(f1) VALUES ('10e-400');
+ ERROR: Bad float8 input format '10e-400' QUERY: INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e-400');
+ ERROR: Bad float8 input format '-10e-400' QUERY: DELETE FROM FLOAT8_TBL; QUERY: INSERT INTO FLOAT8_TBL(f1) VALUES
('0.0');QUERY: INSERT INTO FLOAT8_TBL(f1) VALUES ('-34.84');
barsoom:tih>
> _ NetBSD 1.3 VAX
Unfortunately, I can't run the regression tests under NetBSD/vax, as
my old VAX is having stability problems at the moment. Things were
fine with 6.3, though, and since NetBSD/i386 and NetBSD/sparc both
like 6.4BETA, it's extremely probable that NetBSD/vax will as well.
-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
> I just ran the regression tests on NetBSD/sparc 1.3H, which is an
> interim (current) version between 1.3.2 and 1.4. All tests pass
> except float8, which generates the following extra error messages:
OK, looks good...
- Thomas
Would like to get reports running the Postgres v6.4beta on these
remaining platforms in the next couple of days:
> _ DGUX (needs a new maintainer)
> _ IRIX 6.x (Andrew?)
> _ Digital 4.0
> _ linux 2.0.x Alpha (needs some work; someone have patches?)
> _ NetBSD 1.3 VAX (Tom H's machine is down; anyone else?)
> _ SCO (Billy, have you had any luck with this?)
> _ Solaris x86 (Marc?)
> _ SunOS 4.1.4 Sparc (Tatsuo?)
> _ SVR4 4.4 m88k
TIA
- Tom
On Wed, 28 Oct 1998, Thomas G. Lockhart wrote:
> Would like to get reports running the Postgres v6.4beta on these
> remaining platforms in the next couple of days:
>
> > _ DGUX (needs a new maintainer)
> > _ IRIX 6.x (Andrew?)
> > _ Digital 4.0
> > _ linux 2.0.x Alpha (needs some work; someone have patches?)
> > _ NetBSD 1.3 VAX (Tom H's machine is down; anyone else?)
> > _ SCO (Billy, have you had any luck with this?)
> > _ Solaris x86 (Marc?)
sorry...yes...beautiful build and regression test...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Hi, I just compiled beta4 on Solaris 7 (also known as 2.7) using egcs 1.1. Everything went very smoothly and regression tests were passed. Thomas G. Lockhart writes:> Would like to get reports running the Postgres v6.4beta on these> remaining platforms in thenext couple of days:> > > _ DGUX (needs a new maintainer)> > _ IRIX 6.x (Andrew?)> > _ Digital 4.0> > _ linux 2.0.xAlpha (needs some work; someone have patches?)> > _ NetBSD 1.3 VAX (Tom H's machine is down; anyone else?)> > _ SCO(Billy, have you had any luck with this?)> > _ Solaris x86 (Marc?)> > _ SunOS 4.1.4 Sparc (Tatsuo?)> > _ SVR4 4.4 m88k>> TIA> > - Tom> > MfG/Regards -- /==== Siemens AG / Ridderbusch / , ICP CS XS QM4 / /./ Heinz Nixdorf Ring /=== /,== ,===/ /,==, // 33106 Paderborn, Germany/ // / / // / / \ Tel.: (49) 5251-8-15211 / / `==/\ / / / \ Email: ridderbusch.pad@sni.de Since I have taken all the Gates out of my computer, it finally works!!
Hi,
here are my results for building beta3 on MIPS SVR4. The regression
tests are as good as they can be. There are a couple of changes
necessary, which I've described in a little README, which I've
appended below.
Thomas G. Lockhart writes:> Would like to get reports running the Postgres v6.4beta on these> remaining platforms in
thenext couple of days:> > > _ DGUX (needs a new maintainer)> > _ IRIX 6.x (Andrew?)> > _ Digital 4.0> > _ linux
2.0.xAlpha (needs some work; someone have patches?)> > _ NetBSD 1.3 VAX (Tom H's machine is down; anyone else?)> > _
SCO(Billy, have you had any luck with this?)> > _ Solaris x86 (Marc?)> > _ SunOS 4.1.4 Sparc (Tatsuo?)> > _ SVR4 4.4
m88k>> TIA> > - Tom> >
Readme for building Postgresql 6.4 on Siemens RM Systems
========================================================
1. Overview
===========
This README describes the necessary steps to build the Postgresql
database system on SINIX/Reliant UNIX. Reliant UNIX (previously called
SINIX) is a SVR4 variant, which runs on Siemens RM400/RM600 servers.
These servers use the MIPS R3000/R4400/R10000 family of processors.
The following description is based on SINIX-P 5.42A10 running on a
RM600-xx with 4 processors (both the machine and the operating system
are pretty old, therefore your milage my vary on newer os versions).
2. Building
===========
You can not use the GCC version for this platform (2.7.2.3 from
ftp://ftp.mch.sni.de/sni/mr/pd/gnu). But you have to install it
anyway, since the GCC cpp must be used during an intermediate step,
when header files are produced. You have to use the Siemens
C-compilations environment (I used CDS 1.1A00) for the actual
compilation process. Reason is, that the postgresql backend is build
with several 'ld -R' passes. The linker expects the symbols to be
sorted in ELF object file, which this GCC port apparently does not do.
Apart from flex, bison, you also need GNU awk. Awk is used in
genbki.sh and the expression used in the shell script appears to be
too complex for the system awk. Therefore install GNU awk and make
sure, that this version is found before the system awk (ordering of
PATH variable).
I configured with
./configure --with-template=svr4 \ --prefix=/home/tools/pgsql-6.4 \
--with-includes=/home/tools/include\ --with-libraries=/home/tools/lib
You might be tempted to run configure with the additional argument
--with-CC='cc -W0' to activate the native C-compiler. However, when I
did this, compilation stopped with this error message.
cc -W0 -I../../../include -I../../../backend -I/home/tools/include -I../.. -c istrat.c -o istrat.o istrat.c
496:[error]: 2324 Undefined: 'F_OIDEQ' 2086 c1: errors: 1, warnings: 15
After that the following changes are necessary (the changes are
explicitly listed, since the changes might not be compatible with
other SVR4 platforms, which use the same files):
o Add -lsocket before -lnsl in Makefile.global
o edit Makefile.port and extend LDFLAGS with -lmutex, so that it like this
LDFLAGS+= -lmutex -lc /usr/ucblib/libucb.a -LD-Blargedynsym
And add a line to enable the native C-compiler
CUSTOM_CC = cc -W0 -O2
o configure does not correctly reqognize the number of arguments for gettimeofday. Therefore 'undef'
HAVE_GETTIMEOFDAY_2_ARGS.
o These two patches are necessary to fix a compiler bug.
In backend/utils/adt/date.c around line 179 change
EncodeTimeSpan(tm, 0, DateStyle, buf);
to
EncodeTimeSpan(tm, 0.0, DateStyle, buf);
and in backend/utils/adt/dt.c around line 349 and 359 change
tm2datetime(&tt, 0, NULL, &dt);
to
tm2datetime(&tt, 0.0, NULL, &dt);
Patches in diff -u form are appended below.
o In src/backend/port/Makefile remove the 'strcasecmp.o'.
3. Restrictions
===============
Connecting to the backend via unix domain sockets does not work and
the 64bit data type is not supported. Otherwise the regression test
shows no remarkable differences.
4. Patches
==========
Please remove the first blank column, if you apply the patches.
diff -u src/backend/utils/adt/date.c~ src/backend/utils/adt/date.c--- src/backend/utils/adt/date.c~ Wed Oct 28
20:43:421998+++ src/backend/utils/adt/date.c Wed Oct 28 20:43:42 1998@@ -176,7 +176,7 @@ else {
reltime2tm(time, tm);- EncodeTimeSpan(tm, 0, DateStyle, buf);+ EncodeTimeSpan(tm,
0.0,DateStyle, buf); }
result = palloc(strlen(buf) + 1);diff -u src/backend/utils/adt/dt.c~ src/backend/utils/adt/dt.c---
src/backend/utils/adt/dt.c~ Wed Oct 28 20:45:42 1998+++ src/backend/utils/adt/dt.c Wed Oct 28 20:45:42 1998@@
-346,7+346,7 @@ if (DATETIME_IS_CURRENT(dt)) { GetCurrentTime(&tt);-
tm2datetime(&tt,0, NULL, &dt);+ tm2datetime(&tt, 0.0, NULL, &dt); dt = dt2local(dt,
-CTimeZone);
#ifdef DATEDEBUG@@ -356,7 +356,7 @@ else { /* if
(DATETIME_IS_EPOCH(dt1))*/ GetEpochTime(&tt);- tm2datetime(&tt, 0, NULL, &dt);+
tm2datetime(&tt, 0.0, NULL, &dt); #ifdef DATEDEBUG printf("SetDateTime- epoch time is %f\n", dt);
#endif
MfG/Regards
-- /==== Siemens AG / Ridderbusch / , ICP CS XS QM4 /
/./ Heinz Nixdorf Ring /=== /,== ,===/ /,==, // 33106 Paderborn, Germany/ // / / // / / \ Tel.: (49)
5251-8-15211
/ / `==/\ / / / \ Email: ridderbusch.pad@sni.de
Since I have taken all the Gates out of my computer, it finally works!!
"Thomas G. Lockhart" wrote: > Would like to get reports running the Postgres v6.4beta on these > remaining platforms in the next couple of days: > [...] > > _ SCO (Billy, have you had any luck with this?) Tom, Which SCO? The only port I can support at this time is SCO UnixWare 7 (I no longer have UnixWare 2.x loaded on my machines). The changes I made to support that port should also work for UnixWare 2.x if the UDK (SCO Universal Development Kit) is used to build it, but this has not been tested. Those same changes may also work for SCO OpenServer 5.x, if the UDK is used to build it. I have not done any work with the univel (aka UnixWare 2.x) port for 6.4. I can not say if it will work with 6.4. BTW. Once 6.4 is offically released, I will supply a binary version that should execute on SCO OpenServer 5.x, UnixWare2.x, and UnixWare 7.x. The ability to generate binaries that will run across all of these platforms is the mainreason the UDK exists. -- ____ | Billy G. Allie | Domain....: Bill.Allie@mug.org | /| | 7436 Hartwell | Compuserve: 76337,2061 |-/-|----- | Dearborn, MI 48126| MSN.......: B_G_Allie@email.msn.com |/ |LLIE | (313) 582-1540 |
> > > _ SCO (Billy, have you had any luck with this?)
> Which SCO?
> The only port I can support at this time is SCO UnixWare 7 (I no
> longer have UnixWare 2.x loaded on my machines).
Ah, I was confused, and had thought they were more distinct. Should I
list them separately, or should I just say SCO UnixWare 7 to cover all
current SCO products?
- Tom
Frank Ridderbusch <ridderbusch.pad@sni.de> writes:
> You might be tempted to run configure with the additional argument
> --with-CC='cc -W0' to activate the native C-compiler. However, when I
> did this, compilation stopped with this error message.
> cc -W0 -I../../../include -I../../../backend -I/home/tools/include
> -I../.. -c istrat.c -o istrat.o
> istrat.c 496: [error]: 2324 Undefined: 'F_OIDEQ'
> 2086 c1: errors: 1, warnings: 15
I believe that is the first symptom you'd see when configure chooses
a cpp-from-stdin technique that doesn't actually work. We went around
on that a couple of times in the past three or four days, and eventually
changed the shell scripts so that they don't need cpp from stdin.
So, with the current sources (or BETA4 when it's out) it might work to
specify --with-CC; would you try it and let us know?
This cpp mistake may also be the root of the apparent need to have gcc
installed --- please check and see if that's still true.
> After that the following changes are necessary (the changes are
> explicitly listed, since the changes might not be compatible with
> other SVR4 platforms, which use the same files):
I think all of these config changes could be handled with a special
Makefile.port for Siemens ... is that worth adding?
> o configure does not correctly reqognize the number of arguments
> for gettimeofday. Therefore 'undef' HAVE_GETTIMEOFDAY_2_ARGS.
This should be fixed; can you look into it and see why configure
is getting the wrong answer? Look at configure.in --- there is a
small test program that the script tries to compile, and if there
is no compile error then it assumes gettimeofday has two args.
A first guess is that gettimeofday is not declared in sys/time.h
on your machine. If we add wherever it is declared then perhaps
the test will work.
> o In src/backend/port/Makefile remove the 'strcasecmp.o'.
Likewise, this should be fixable by improving configure's test
to see whether the system has strcasecmp.
regards, tom lane
Tom Lane writes:> Frank Ridderbusch <ridderbusch.pad@sni.de> writes:> > You might be tempted to run configure with the
additionalargument
....> > This cpp mistake may also be the root of the apparent need to have gcc> installed --- please check and see if
that'sstill true.
Once beta4 is ready I will definitely rebuild.
> > After that the following changes are necessary (the changes are> > explicitly listed, since the changes might not
becompatible with> > other SVR4 platforms, which use the same files):> > I think all of these config changes could be
handledwith a special> Makefile.port for Siemens ... is that worth adding?
Well I'd say, this short before your expected release date, I wouldn't
want to shake things up by adding another special Makefile.port with
the possible iterations to get it right. And although I would like it
to be otherwise, Siemens RM system have only a great market share in
Germany. I think, if Pyramid Nile users and, I think NEC has/had a MIPS
based SVR4, would speak up, then you should add a special MIPS based
Makefile.port
> > o configure does not correctly reqognize the number of arguments> > for gettimeofday. Therefore 'undef'
HAVE_GETTIMEOFDAY_2_ARGS.>> This should be fixed; can you look into it and see why configure> is getting the wrong
answer? Look at configure.in --- there is a> small test program that the script tries to compile, and if there> is no
compileerror then it assumes gettimeofday has two args.> A first guess is that gettimeofday is not declared in
sys/time.h>on your machine. If we add wherever it is declared then perhaps> the test will work.
As I say, my system is pretty old (still R3000) and ths os is just as
old. And indeed the missing prototype in sys/time.h is the
cause. Later OS version have it defined. Therefore I really see no
need for changes here.
> > o In src/backend/port/Makefile remove the 'strcasecmp.o'.> > Likewise, this should be fixable by improving
configure'stest> to see whether the system has strcasecmp.> > regards, tom lane
Well, this problem is originally caused by the need to link against
/usr/ucblib/libucb.a. Without libucb.a, I'm getting three undefined
symbols
strncasecmp commands/SUBSYS.oalloca bootstrap/SUBSYS.ostrcasecmp
commands/SUBSYS.o
alloca is ok (GCC users have it build in). But strncasecmp and
strcasecmp are defined in the same archive member in
libucb.a. Therefore I get multiple defines if I link with strcasecmp.o
from pgsql.
Come to think of it, shouldn't configure check also for strncasecmp if
it checks for strcasecmp? But apparently, since no one complains, it
appears, that all other platforms do have strncasecmp and shouldn't
also need strcasecmp.
I general, I would say, leave the configure process as it is, once
beta4 is available. I'm quite happy as it stand, with all the
shortcommings of my dated hard- and software.
Regards,
Frank
Frank Ridderbusch <ridderbusch.pad@sni.de> writes:
>> Likewise, this should be fixable by improving configure's test
>> to see whether the system has strcasecmp.
> Well, this problem is originally caused by the need to link against
> /usr/ucblib/libucb.a. Without libucb.a, I'm getting three undefined
> symbols
> strncasecmp commands/SUBSYS.o
> alloca bootstrap/SUBSYS.o
> strcasecmp commands/SUBSYS.o
> alloca is ok (GCC users have it build in). But strncasecmp and
> strcasecmp are defined in the same archive member in
> libucb.a. Therefore I get multiple defines if I link with strcasecmp.o
> from pgsql.
OK, the reason that configure is deciding strcasecmp.o is needed is that
it has no idea you are planning to link with /usr/ucblib/libucb.a.
Rather than editing the generated makefiles after the fact, you might
have better luck if you edit the template file you plan to use *before*
running configure. I think adding "-L/usr/ucblib -lucb" to the LIBS
line in the template file would solve this particular problem. I think
you had mentioned needing a few other unusual libraries as well --- you
should be able to take care of all of them that way.
> Come to think of it, shouldn't configure check also for strncasecmp if
> it checks for strcasecmp? But apparently, since no one complains, it
> appears, that all other platforms do have strncasecmp and shouldn't
> also need strcasecmp.
Basically configure is assuming that your system library provides
both or neither. I think that's a reasonable assumption. Of course,
if we find any actual instances of systems with just one, we may have
to change it...
regards, tom lane