Last call?

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, Pennsylvania 19026

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 ID 32B8FAA1
========================================
"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

My stuff is all in, as of yesterday. (BTW, I assume it's sufficient
to fix install.sgml, and that the text INSTALL file will be built from
that?)

Yes. And I'm going through install.sgml at this moment to freshen it up.
I'll commit changes in the next few minutes, and it would be great if
others (Tom and Bruce?) could take a look at it.

I'll try posting a new html version of things on the Postgres web site.

- 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, Pennsylvania 19026

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?):

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

I'll try posting a new html version of things on the Postgres web
site.

... which I've now done for the admin guide. This contains a chapter on
installation which is from the same source as the text-only version to
be put in INSTALL.

Could folks look it over and in particular make sure that it is an
acceptable substitute for what is now in INSTALL?

- Tom

My stuff is all in, as of yesterday. (BTW, I assume it's sufficient
to fix install.sgml, and that the text INSTALL file will be built from
that?)

Yes. And I'm going through install.sgml at this moment to freshen it up.
I'll commit changes in the next few minutes, and it would be great if
others (Tom and Bruce?) could take a look at it.

I'll try posting a new html version of things on the Postgres web site.

- Tom

As far as I know, the INSTALL and sgml INSTALL are in sync. I have made
changes both places, and I don't think others have made changes.

-- 
  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, Pennsylvania 19026

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

I compiled it on RH 5.1... no problems.

Taral

Show quoted text

-----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:

Show quoted text

'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 cannot believe, RH4.2 isn't a glibc2 system.

-Egon

On Sun, 25 Oct 1998, Terry Mackintosh wrote:

Show quoted text

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:

Show quoted text

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 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?

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 their machine 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 ID 32B8FAA1
========================================
"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 does not 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 think you messed up a change I had made: the version of install.sgml
I committed yesterday had the steps:
...
initdb
check permissions
start postmaster
run regression test
<substeps>
arrange for postmaster autostart
...
You seem to have undone that in a way that's broken...

OK, I know I messed it up. I was confused the whole way, and *it's
because you have the same *(&^% username as I've had for 20 years* :)

I had seen that you had committed changes, and then I'd had cvs merging
difficulties because I was also making changes to that file. But then
when trying to resolve the patches I chose the wrong block of changes in
at least one case, and got confused when seeing that "tgl" had made the
changes.

Anyway, will go through it again.

Your tags were just fine afaik. I have since gone through and put lots
more markup in because it was never done the first time when I copied
INSTALL to become install.sgml.

- Tom^H^H^HThomas

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

Hi All,

Looks fine here, although we did change from BST to GMT last night!!

In general PostgreSQL on S/Linux is looking good.

I'm running kernel 2.0.35 on a mainly Redhat 4.2 system.

The only regression failures are float8 and geometry, due
to the usual FP rounding/precision differences.

Thanks,
Keith.

"Billy G. Allie" <Bill.Allie@mug.org>

"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
does not exist :-)

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

Show quoted text

-----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

_ FreeBSD 2.2.x-3.x
_ NetBSD 1.3
_ HPUX 9.x
_ HPUX 10.20

Hi Stan. I have a recent report of success on NetBSD-1.3.2/x86; don't
know which CPU or OS rev you are running and I still need reports for
NS32532, Sparc, and VAX variants. Also, the HPUX ones have one report
each (along with some patches to get the hp compiler to work with it;
these are now in the main tree).

I haven't gotten a report yet for FreeBSD (I'm guessing that I may see
one from Marc/scrappy), and I'd like to see a second report for the
other three, but they aren't absolutely essential.

So, I still need FreeBSD and, depending on your NetBSD rev and
environment, that one too.

TIA

- Tom

_ 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

x Windows NT

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.

Yes, it is really "mostly working ..." (no dynamic loaded code yet, some
other unsuccessful regression tests) and there is a website
http://www.askesis.nl/AskesisPostgresIndex.html dedicated to this port. Here
are all the patches, some porting infos, etc.

Dan Horak

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/ |
----------------------------------------------------------------------------

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.

Yes, it is really "mostly working ..." (no dynamic loaded code yet, some
other unsuccessful regression tests) and there is a website
http://www.askesis.nl/AskesisPostgresIndex.html dedicated to this port. Here
are all the patches, some porting infos, etc.

I have added this to the FAQ:

The database server is now working on Windows NT using the Cygnus
Unix/NT porting library. The only feature missing is dynamic loading of
user-defined functions/types. See
http://www.askesis.nl/AskesisPostgresIndex.html for more information.

I have removed the pg_version table, so your pg_ver fix is no longer
needed. This should shrink down the patch quite a bit. If it is small
enough, we can integrate it into the next minor release. Of course, you
should continue maintaining the page as you improve the port.

-- 
  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, Pennsylvania 19026

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) #

"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:

... which I've now done for the admin guide. This contains a chapter on
installation which is from the same source as the text-only version to
be put in INSTALL.
Could folks look it over and in particular make sure that it is an
acceptable substitute for what is now in INSTALL?

A couple minor comments:

1. I think the disk space estimates are now too low. Yesterday I
measured the required space to build/install/do regression test on an
HPUX 10.20 box, which is probably not too unrepresentative of RISC-type
workstations. The source tree got up to 29600K, the installed code +
initdb took about 4600K, and the regression test database occupied
18500K. Furthermore, I did not build Tcl, Perl, or ODBC libraries,
which would certainly have increased the build space and installed code
size by a few more megs. Still more: the source tree included the
formatted doc files (those tar.gz files in doc/) that are currently in
the CVS server. I assume that 6.4's formatted doc files will be
substantially bulkier, thanks to Thomas' tireless efforts ;-). And
still more: I didn't do an install of the documentation files. So you
need to add whatever the installed footprint of the html, ps, and
man-page files are.

The estimates given in the INSTALL docs (45MB peak usage during build &
install, 3MB permanent footprint) are probably at least 50% too low.
We've been busy little builders, evidently :-).

It's probably not necessary to repeat the disk space estimates twice,
either. Step 3a of the install procedure ought to be merged into the
"Requirements to run Postgres" section.

2. In install step 2 ("Create the Postgres superuser account...")
it wouldn't hurt to add "The owner of the Postgres files can be any
unprivileged user account. It MUST NOT be root, bin, or any other
account with special access rights, as that would create a security risk."
This point is made later, but the time that an installer needs to know
it is right here.

3. In step 6 (dumping your old database) I think that the dumpall
command should include -z:
$ src/bin/pg_dump/pg_dumpall -z > db.out
Otherwise table ownership will not be preserved, which could ruin
someone's day. (BTW, is there really any value in extracting the
pg_dumpall script from the distribution as shown? Most of the problems
we've fixed in database dumping have been inside pg_dump, methinks.
So it's not clear that this contortion helps anything.)

4. (I mentioned this one already.) Step 19a (start postmaster,
as a substep of running the regression tests) probably ought to be
a top-level step between 18 and 19. You want people to do it even
if they skip the regression test.

regards, tom lane

On 27-Oct-98 Tom Lane wrote:

"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:

The estimates given in the INSTALL docs (45MB peak usage during build &
install, 3MB permanent footprint) are probably at least 50% too low.
We've been busy little builders, evidently :-).

On FreeBSD 2.2.6, I'm just a few K under 50MB for build and install. If
the regression tests went beyond that I dunno.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
# include <std/disclaimers.h> TEAM-OS2
Online Searchable Campground Listings http://www.camping-usa.com
"There is no outfit less entitled to lecture me about bloat
than the federal government" -- Tony Snow
==========================================================================

On Mon, 26 Oct 1998, Thomas G. Lockhart wrote:

_ FreeBSD 2.2.x-3.x
_ NetBSD 1.3
_ HPUX 9.x
_ HPUX 10.20

Hi Stan. I have a recent report of success on NetBSD-1.3.2/x86; don't
know which CPU or OS rev you are running and I still need reports for
NS32532, Sparc, and VAX variants. Also, the HPUX ones have one report
each (along with some patches to get the hp compiler to work with it;
these are now in the main tree).

I haven't gotten a report yet for FreeBSD (I'm guessing that I may see
one from Marc/scrappy), and I'd like to see a second report for the
other three, but they aren't absolutely essential.

So, I still need FreeBSD and, depending on your NetBSD rev and
environment, that one too.

Building and doing regression tests as i type...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

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

Could folks look it over and in particular make sure that it is an
acceptable substitute for what is now in INSTALL?

All good suggestions. Will make some mods.

btw, I just realized that "config.sgml" was not being built into the
Admin Guide. It includes sections on enabling locale and on configuring
Kerberos. I've added a section which is essentially the "configure
options" as is in the installation procedure; I'd propose expanding on
that and dropping most of the verbiage in that step of the installation.

I will also add a section on "make options", inspired by that same kind
of info in the ODBC installation docs. It will likely not be complete,
but it's a start.

Will try to knock this off soon (tonight?) and check in sources and post
html on the web site. Also, will try another cut at globbing sections
together to make a new INSTALL. Bruce, can you give some feedback on
that? I would like to know what info should be added or removed and what
you find most annoying about the formatting. I can make adjustments, but
need to hear what you would like.

TIA

- Tom

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 domain sockets are ok)
On the other hand, 2.1.1xx kernels do support PCMCIA,
unfortunately, these are broken in that using the 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_TBL WHERE
d1 = 'today'::datetime; --> no row selected

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?

(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

"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:

Hi Stan. I have a recent report of success on NetBSD-1.3.2/x86; don't
know which CPU or OS rev you are running and I still need reports for
NS32532, Sparc, and VAX variants.

I'll try to find time to regression test NetBSD/sparc tonight. My VAX
is having problems right now, so that won't be possible, I'm afraid.
No real reason to think it should be broken, but I guess it'll just
have to be listed as unsupported, but probably OK.

-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"

I'll try to find time to regression test NetBSD/sparc tonight. My VAX
is having problems right now, so that won't be possible, I'm afraid.
No real reason to think it should be broken, but I guess it'll just
have to be listed as unsupported, but probably OK.

I'm planning on leaving the supported machine info the same, so it will
show that it was tested under v6.3.x. I'll also have a comment that
machines which worked on v6.3 should work on v6.4. But of course it
would be best to get new info when possible.

- Tom^H^H^HThomas

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

"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: INSERT INTO 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

_ NetBSD 1.3 NS32532

Sorry I can't confirm or deny that this works on my machine right
now. I tried to upgrade it to NetBSD-current a couple of months
ago, and mostly got there.

I don't have my heart set on v1.3, the NS32532 and the NetBSD is the
interesting part. If -current can build the system, then I'm happy to
report that version. I'll go ahead and do that, unless you say that it
would be erroneous to do so.

Might want to say that it "mostly works" with known problems in some
of the date code, and possibly other bugs, but still mostly usable.
(I don't suspect that too many people will be running this on a NS32K
machine anyway.)

OK.

- 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 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

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 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

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:42 1998
 +++ 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, UnixWare 2.x, and UnixWare 7.x. The ability to generate binaries that will run across all of these platforms is the main reason 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 additional argument

....

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.

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 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?

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 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.

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's test
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.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.

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