Horton

Thread

  1. Call for port testing on fmgr changes

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-06-14T16:55:20Z

    I have finished updating about half of Postgres' builtin functions to
the new style of fmgr interface.  At this point, everything that accepts
any pass-by-value datatypes is converted; the remaining work is for
functions that use only pass-by-reference datatypes, and therefore
receive only pointer arguments.

This should already take care of function-call-related portability
problems on many platforms.  In particular these changes should
eliminate the need for Ryan Kirkpatrick's Linux/Alpha patches, and
should also solve the known problems on PPC builds with optimization
higher than -O0.  We might be able to increase the optimization level
on other platforms that have had trouble with function-call
optimizations, too.

I'd like to get the current code tested by some people with Alphas
(or other 64-bit platforms), PPCs, and anything else that has had
optimization-related problems.  You can get the 7.1 development code
from our CVS server, or use the current daily-snapshot tarball (see
ftp://ftp.postgresql.org/pub/dev/).

			regards, tom lane

  2. Re: [HACKERS] Call for port testing on fmgr changes

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-06-14T17:01:26Z

    > eliminate the need for Ryan Kirkpatrick's Linux/Alpha patches, and
> should also solve the known problems on PPC builds with optimization
> higher than -O0.  We might be able to increase the optimization level

I have change the -O0 to -O2.

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

  3. Re: Call for port testing on fmgr changes

    Ryan Kirkpatrick <pgsql@rkirkpat.net> — 2000-06-16T13:14:22Z

    On Wed, 14 Jun 2000, Tom Lane wrote:

> I have finished updating about half of Postgres' builtin functions to
> the new style of fmgr interface.  At this point, everything that accepts
> any pass-by-value datatypes is converted; the remaining work is for
> functions that use only pass-by-reference datatypes, and therefore
> receive only pointer arguments.

	Cool! I need to study up a bit on fmgr, but anything that help
Linux/Alpha is a good thing. :)

> This should already take care of function-call-related portability
> problems on many platforms.  In particular these changes should
> eliminate the need for Ryan Kirkpatrick's Linux/Alpha patches, and

	Not all of my Linux/Alpha patches are related to fmgr, there are a
few related to s_lock and such (which can probably be put into the source
tree with #ifdefs). But this should take care of the majority of the
Linux/Alpha patch.
	I will download the snapshot today at work (where I have "real"
bandwidth :) and test things out this weekend. I should have a report by
Monday. Maybe I will even have a patch that can be safely applied to
the development source tree. :) TTYL.

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------

  4. Re: [HACKERS] Re: Call for port testing on fmgr changes

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-06-16T14:46:35Z

    Ryan Kirkpatrick <pgsql@rkirkpat.net> writes:
> 	Not all of my Linux/Alpha patches are related to fmgr, there are a
> few related to s_lock and such (which can probably be put into the source
> tree with #ifdefs).

Right-o.  Up to now we haven't worried about that, but now that the
fundamental problem is fixed (I hope), we can start cleaning up the
smaller details so that Linux/Alpha will be supported out-of-the-box.

			regards, tom lane

  5. Re: Call for port testing on fmgr changes -- Results!

    Ryan Kirkpatrick <pgsql@rkirkpat.net> — 2000-06-18T22:43:03Z

    On Fri, 16 Jun 2000, Ryan Kirkpatrick wrote:

> 	I will download the snapshot today at work (where I have "real"
> bandwidth :) and test things out this weekend. I should have a report by
> Monday. Maybe I will even have a patch that can be safely applied to
> the development source tree. :) TTYL.

	Ok, I have tested the new snapshot. I have good news and I have
bad news...
	First of all, to build pgsql correctly from the snapshot tarball
(dated Fri, Jun 16th), I had to run a 'make distclean' first. There were
some config.status files laying around that were confusing the configure
run. Don't know if that is just par for pgsql devel snapshots or if there
was mistake somewhere in the building of the snapshot.
	Once I got past that, I realized that the only non-fmgr related
Linux/Alpha patch was a adding a single line to the linux_alpha template
file. If I had realized that earlier, I would have submitted that patch
long ago. But it is attached now, probably not even work using 'patch' on
(i.e. easier to hand code it in), and really should not break any other
platforms. :)
	Now, for the fmgr rewrite testing... I compiled pgsql w/o any
patches or source code modifications save for the two I mentioned above
(make distclean and added line to linux_alpha template). 'initdb' ran
without problems. Regression tests failed on geometry as expected (off by
one in nth decimal place), but also failed on timestamp, tinterval,
horology, and abstime. These latter failures were characteristic of
running release versions of pgsql w/o the Linux/Alpha patches. Years that
are several centuries off. :(
	I tracked the problem down to the following suspect functions. I
found these as they were functions listed in the Linux/Alpha patches (as
needing Datum datatypes for function params), but did not appear to have
been rewritten from the new fmgr (i.e. no PG_FUNCTION_ARGS in
declaration). These functions are all in src/backend/utils/adt/nabstime.c.
	abstime2tm
	tm2abstime
	AbsoluteTimeIsBefore
	AbsoluteTimeIsAfter
	reltime2tm
If these are converted to the new fmgr format, then I think the regression
tests mentioned above should pass on Linux/Alpha. I think I will leave the
conversion to some one who is more familiar with the new fmgr than me.
	Once that is done, and the attached patch is applied to the source
tree, there is a very good chance that pgsql will FINALLY work out of the
box on Linux/Alpha. :)
	Let me know when the new fmgr is ready to test again, if you
need any more information on the above, or if there is anything else I can
do help this process. TTYL.

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------

  6. Re: Re: Call for port testing on fmgr changes -- Results!

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-06-19T00:51:11Z

    Applied.


> On Fri, 16 Jun 2000, Ryan Kirkpatrick wrote:
> 
> > 	I will download the snapshot today at work (where I have "real"
> > bandwidth :) and test things out this weekend. I should have a report by
> > Monday. Maybe I will even have a patch that can be safely applied to
> > the development source tree. :) TTYL.
> 
> 	Ok, I have tested the new snapshot. I have good news and I have
> bad news...
> 	First of all, to build pgsql correctly from the snapshot tarball
> (dated Fri, Jun 16th), I had to run a 'make distclean' first. There were
> some config.status files laying around that were confusing the configure
> run. Don't know if that is just par for pgsql devel snapshots or if there
> was mistake somewhere in the building of the snapshot.
> 	Once I got past that, I realized that the only non-fmgr related
> Linux/Alpha patch was a adding a single line to the linux_alpha template
> file. If I had realized that earlier, I would have submitted that patch

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

  7. Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-06-19T05:17:18Z

    Ryan Kirkpatrick <pgsql@rkirkpat.net> writes:
> 	First of all, to build pgsql correctly from the snapshot tarball
> (dated Fri, Jun 16th), I had to run a 'make distclean' first. There were
> some config.status files laying around that were confusing the configure
> run.

That's odd, the snapshot is supposed to have been made from a
distcleaned directory tree.  Maybe something busted in the snapshot
generation script?  Marc?

> 	I tracked the problem down to the following suspect functions. I
> found these as they were functions listed in the Linux/Alpha patches (as
> needing Datum datatypes for function params), but did not appear to have
> been rewritten from the new fmgr (i.e. no PG_FUNCTION_ARGS in
> declaration). These functions are all in src/backend/utils/adt/nabstime.c.
> 	abstime2tm
> 	tm2abstime
> 	AbsoluteTimeIsBefore
> 	AbsoluteTimeIsAfter
> 	reltime2tm
> If these are converted to the new fmgr format, then I think the regression
> tests mentioned above should pass on Linux/Alpha.

Hmm.  I did not touch these because they aren't fmgr-callable (and in
fact I feel fairly safe in saying that AbsoluteTimeIsAfter isn't called
period, since it's ifdef'd out...).  As best I can tell, the other four
are only called from places that see valid prototypes for them, so if
your compiler is failing to call them correctly then your compiler is
broken.

I suspect that the real problem is not call sequences, but something
else that happens to be affecting these routines (and maybe related code
that doesn't get exercised by the regression tests).  Maybe something
like macro-constants that are declared with not quite the right type
(unsigned or not, long or not) and need to be casted to match whatever
they're being compared to.  We've seen that before.

Could you dig a little more and try to identify exactly what's
going wrong?

Anyway, it sure sounds like we've broken the back of the problems.
Couple more bug fixes and we'll be there.  That's good news indeed!

			regards, tom lane

  8. Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!

    Ryan Kirkpatrick <pgsql@rkirkpat.net> — 2000-06-20T23:15:25Z

    On Mon, 19 Jun 2000, Tom Lane wrote:

> > declaration). These functions are all in src/backend/utils/adt/nabstime.c.
> > 	abstime2tm
> > 	tm2abstime
> > 	AbsoluteTimeIsBefore
> > 	AbsoluteTimeIsAfter
> > 	reltime2tm
> 
> Hmm.  I did not touch these because they aren't fmgr-callable (and in
...
> I suspect that the real problem is not call sequences, but something
> else that happens to be affecting these routines (and maybe related code
...
> they're being compared to.  We've seen that before.
> Could you dig a little more and try to identify exactly what's
> going wrong?

	Will do. I ran out of time last weekend to actually test if these
functions were the cause of the problem or not. They just looked suspcious
given the patches I had. I will did deeper and see what I can find, but it
will probably not happen until next weekend. Will post when I have found
something.

> Anyway, it sure sounds like we've broken the back of the problems.
> Couple more bug fixes and we'll be there.  That's good news indeed!

	Yes, very good news indeed! :)

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------

  9. Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!

    Tatsuo Ishii <t-ishii@sra.co.jp> — 2000-06-25T02:46:20Z

    > On Mon, 19 Jun 2000, Tom Lane wrote:
> 
> > > declaration). These functions are all in src/backend/utils/adt/nabstime.c.
> > > 	abstime2tm
> > > 	tm2abstime
> > > 	AbsoluteTimeIsBefore
> > > 	AbsoluteTimeIsAfter
> > > 	reltime2tm
> > 
> > Hmm.  I did not touch these because they aren't fmgr-callable (and in
> ...
> > I suspect that the real problem is not call sequences, but something
> > else that happens to be affecting these routines (and maybe related code
> ...
> > they're being compared to.  We've seen that before.
> > Could you dig a little more and try to identify exactly what's
> > going wrong?
> 
> 	Will do. I ran out of time last weekend to actually test if these
> functions were the cause of the problem or not. They just looked suspcious
> given the patches I had. I will did deeper and see what I can find, but it
> will probably not happen until next weekend. Will post when I have found
> something.

Tamotsu Nakagawa has posted a fix for this to a local mail list in
Japan. Can someone comment on this? According to him, with the patch
now only the geometry test fails.

 void
-abstime2tm(AbsoluteTime time, int *tzp, struct tm * tm, char *tzn)
+abstime2tm(AbsoluteTime _time, int *tzp, struct tm * tm, char *tzn)
 {
+       time_t time = (time_t) _time;
 #ifdef USE_POSIX_TIME
        struct tm  *tx;

  10. Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-06-25T04:15:44Z

    Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> Tamotsu Nakagawa has posted a fix for this to a local mail list in
> Japan. Can someone comment on this? According to him, with the patch
> now only the geometry test fails.

>  void
> -abstime2tm(AbsoluteTime time, int *tzp, struct tm * tm, char *tzn)
> +abstime2tm(AbsoluteTime _time, int *tzp, struct tm * tm, char *tzn)
>  {
> +       time_t time = (time_t) _time;
>  #ifdef USE_POSIX_TIME
>         struct tm  *tx;

Hmm, that makes all kinds of sense if time_t is not the same size as
AbsoluteTime --- which wouldn't surprise me at all on a 64-bit system.
time_t *ought* to be 64-bits on such a machine.  The casts in that
routine,
		tx = localtime((time_t *) &time);
are obviously bogus if so.  Can anyone with an Alpha comment?

What surprises me more is the implication that this is the only place
that makes such a bogus assumption about the size of time_t.  I'd have
guessed there are more places...

			regards, tom lane

  11. Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2000-06-25T04:36:13Z

    > Hmm, that makes all kinds of sense if time_t is not the same size as
> AbsoluteTime --- which wouldn't surprise me at all on a 64-bit system.
> time_t *ought* to be 64-bits on such a machine.  The casts in that
> routine,
>                 tx = localtime((time_t *) &time);
> are obviously bogus if so.  Can anyone with an Alpha comment?

I haven't had an Alpha for a couple of years, but I *strongly* recall
that time_t is 64 bits on that machine.

               - Thomas

  12. Re: Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!

    Adriaan Joubert <a.joubert@albourne.com> — 2000-06-25T07:17:52Z

    Thomas Lockhart wrote:

> > Hmm, that makes all kinds of sense if time_t is not the same size as
> > AbsoluteTime --- which wouldn't surprise me at all on a 64-bit system.
> > time_t *ought* to be 64-bits on such a machine.  The casts in that
> > routine,
> >                 tx = localtime((time_t *) &time);
> > are obviously bogus if so.  Can anyone with an Alpha comment?
>
> I haven't had an Alpha for a couple of years, but I *strongly* recall
> that time_t is 64 bits on that machine.
>

In <sys/types.h> time_t is defined as an int4, i.e. 4 bytes. To
double-check I wrote a program to print sizeof:

sizeof(time_t)=4         (DU 4.0F, cc)

So I guess it is 32 bits. On the whole they have stuck to traditional sizes
for traditional types -- it would just have broken too many programmes
otherwise. Of course they are going to have to make time_t 64 bits within
the next 30 years ....

Adriaan

  13. Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!

    Ryan Kirkpatrick <pgsql@rkirkpat.net> — 2000-06-25T15:31:53Z

    On Sun, 25 Jun 2000, Tom Lane wrote:

> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > Tamotsu Nakagawa has posted a fix for this to a local mail list in
> > Japan. Can someone comment on this? According to him, with the patch
> > now only the geometry test fails.
> 
> >  void
> > -abstime2tm(AbsoluteTime time, int *tzp, struct tm * tm, char *tzn)
> > +abstime2tm(AbsoluteTime _time, int *tzp, struct tm * tm, char *tzn)
> >  {
> > +       time_t time = (time_t) _time;
> >  #ifdef USE_POSIX_TIME
> >         struct tm  *tx;
> 
> Hmm, that makes all kinds of sense if time_t is not the same size as
> AbsoluteTime --- which wouldn't surprise me at all on a 64-bit system.
> time_t *ought* to be 64-bits on such a machine.  The casts in that
> routine,
> 		tx = localtime((time_t *) &time);
> are obviously bogus if so.  Can anyone with an Alpha comment?

	On Linux/Alpha, time_t is indeed 64 bit (i.e.
printf("%d\n",sizeof(time_t)) results in an '8'). If AbsoluteTime is only
32 bit, then that would definitely cause a problem.

> What surprises me more is the implication that this is the only place
> that makes such a bogus assumption about the size of time_t.  I'd have
> guessed there are more places...

	I will apply the above patch, check for other instances of time_t
size assumptions, and see what the result is this afternoon. TTYL.

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------

  14. Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!

    Ryan Kirkpatrick <pgsql@rkirkpat.net> — 2000-06-25T22:08:55Z

    > > >  void
> > > -abstime2tm(AbsoluteTime time, int *tzp, struct tm * tm, char *tzn)
> > > +abstime2tm(AbsoluteTime _time, int *tzp, struct tm * tm, char *tzn)
> > >  {
> > > +       time_t time = (time_t) _time;
> > >  #ifdef USE_POSIX_TIME
> > >         struct tm  *tx;
> > 

	Ok, the above patch does indeed solve the problem. And this
appears to be the only place AbsoluteTime needs to be copied to a time_t
variable. I can't find any other casts of AbsoluteTime to time_t, and
with this patch applied all regression tests pass just fine (save for
geometry of course with its standard off by one in nth decimal place
difference).
	Additionally, I do not see how this patch could break other
platforms. At worst, it is a minor slow down that might even be optimized
out by some compiliers when they see that sizeof(AbsoluteTime) ==
sizeof(time_t). I will defer to the core developers on how you want to
apply this patch to the source tree (i.e. with #ifdef alpha && linux or as
above). Though probably best to add a bit of a comment beside it so
someone does not remove it later thinking they are "optimizing" the code.
:)
	At this point, Linux/Alpha should actually run out of the box! Let
me know when this patch is applied (in what ever form it ends up as) and I
will download a new snapshot and test it. 
	TTYL.

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------

  15. Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!

    Peter Eisentraut <peter_e@gmx.net> — 2000-06-26T01:41:50Z

    Tom Lane writes:

> What surprises me more is the implication that this is the only place
> that makes such a bogus assumption about the size of time_t.  I'd have
> guessed there are more places...

A lot of those were fixed for 7.0.

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

  16. Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-06-26T03:31:39Z

    Ryan Kirkpatrick <pgsql@rkirkpat.net> writes:
> 	Ok, the above patch does indeed solve the problem. And this
> appears to be the only place AbsoluteTime needs to be copied to a time_t
> variable. I can't find any other casts of AbsoluteTime to time_t,

Great!

> and
> with this patch applied all regression tests pass just fine (save for
> geometry of course with its standard off by one in nth decimal place
> difference).

Probably we should write that off as a platform issue and create an
Alpha-specific expected-output file for geometry.  See the documentation
about platform-specific files, and please send along a patch to add one.

> 	Additionally, I do not see how this patch could break other
> platforms. At worst, it is a minor slow down that might even be optimized
> out by some compiliers when they see that sizeof(AbsoluteTime) ==
> sizeof(time_t). I will defer to the core developers on how you want to
> apply this patch to the source tree (i.e. with #ifdef alpha && linux or as
> above).

No, we should just apply it as is, no #ifdef.  There are going to be
more and more platforms with 64-bit time_t.

			regards, tom lane

  17. Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!

    Peter Eisentraut <e99re41@docs.uu.se> — 2000-06-26T12:29:43Z

    On Sun, 25 Jun 2000, Tom Lane wrote:

> Probably we should write that off as a platform issue and create an
> Alpha-specific expected-output file for geometry.

I noticed the other day that the geometry output differs with the
compiler optimization level. That can't be good.


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden

  18. Re: [HACKERS] Re: Call for port testing on fmgr changes --Results!

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2000-06-26T13:17:37Z

    > I noticed the other day that the geometry output differs with the
> compiler optimization level. That can't be good.

It depends where the differences are. If they are just in the last few
decimal places, then it should be OK (though annoying for regression
test support).

With higher optimizations, they may be doing more inlining and using
different code sequences for, for example, the transcendental functions.

                     - Thomas

  19. Re: [PORTS] Re: Re: Call for port testing on fmgr changes --Results!

    Adriaan Joubert <a.joubert@albourne.com> — 2000-06-26T13:29:40Z

    Thomas Lockhart wrote:

> > I noticed the other day that the geometry output differs with the
> > compiler optimization level. That can't be good.
>
> It depends where the differences are. If they are just in the last few
> decimal places, then it should be OK (though annoying for regression
> test support).
>
> With higher optimizations, they may be doing more inlining and using
> different code sequences for, for example, the transcendental functions.

Dunno which flags you used, but with the right flags you get faster
versions of the built-in library routines -- I know that for sine/cosine
etc this makes a significant difference in runtime for a very small loss in
accuracy. And aggressive reordering of instructions can mean that different
parts of the calculation are executed in different order (if I recall
correctly EV6/7s have 8 fp/int pipes) so that small differences in
end-results are to be expected. But then, the last few digits are garbage
in most numerical calculations anyway, so no great harm done there.

The right way to solve this would be to be able to control the number of
digits that are printed, so that it is easier to check that the significant
digits are the same.  That would probably get rid of quite a few
architecture specific files regression test files as well.

Adriaan

  20. Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!

    Ryan Kirkpatrick <pgsql@rkirkpat.net> — 2000-06-27T00:36:02Z

    On Sun, 25 Jun 2000, Tom Lane wrote:

> > with this patch applied all regression tests pass just fine (save for
> > geometry of course with its standard off by one in nth decimal place
> > difference).
> 
> Probably we should write that off as a platform issue and create an
> Alpha-specific expected-output file for geometry.  See the documentation
> about platform-specific files, and please send along a patch to add one.

	I remember finding a geometry.out file in the expected directory
that did match. Seems to me it was a Solaris/Sun one.... Anyway, I will
look into it and generate a patch to rid ourselves of that annoyance.
Probably will be next Sunday before it happens.
	As for the comments about different geometry outputs with
different optimization levels, the linux_alpha template is set to use -O2,
which seems pretty standard for safe, yet useful optimization. Though I
have had reports that newer versions of gcc (from Mandrake 7.1) break
pgsql (spinlocks get stuck) with that optimization level. My alpha is
still running Debian 2.1 and so my gcc is a little old. Probably will
upgrade before the end of the summer and have to deal with that issue
then. Yuck. :( Of course, if some one wants to beat me to it, feel free :)

> > 	Additionally, I do not see how this patch could break other
> > platforms. At worst, it is a minor slow down that might even be optimized
> > out by some compiliers when they see that sizeof(AbsoluteTime) ==
> > sizeof(time_t). I will defer to the core developers on how you want to
> > apply this patch to the source tree (i.e. with #ifdef alpha && linux or as
> > above).
> 
> No, we should just apply it as is, no #ifdef.  There are going to be
> more and more platforms with 64-bit time_t.

	No problem here with that, go ahead and apply it.

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------

  21. Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results!

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-06-27T18:08:05Z

    Applied as you suggested.


> > On Mon, 19 Jun 2000, Tom Lane wrote:
> > 
> > > > declaration). These functions are all in src/backend/utils/adt/nabstime.c.
> > > > 	abstime2tm
> > > > 	tm2abstime
> > > > 	AbsoluteTimeIsBefore
> > > > 	AbsoluteTimeIsAfter
> > > > 	reltime2tm
> > > 
> > > Hmm.  I did not touch these because they aren't fmgr-callable (and in
> > ...
> > > I suspect that the real problem is not call sequences, but something
> > > else that happens to be affecting these routines (and maybe related code
> > ...
> > > they're being compared to.  We've seen that before.
> > > Could you dig a little more and try to identify exactly what's
> > > going wrong?
> > 
> > 	Will do. I ran out of time last weekend to actually test if these
> > functions were the cause of the problem or not. They just looked suspcious
> > given the patches I had. I will did deeper and see what I can find, but it
> > will probably not happen until next weekend. Will post when I have found
> > something.
> 
> Tamotsu Nakagawa has posted a fix for this to a local mail list in
> Japan. Can someone comment on this? According to him, with the patch
> now only the geometry test fails.
> 
>  void
> -abstime2tm(AbsoluteTime time, int *tzp, struct tm * tm, char *tzn)
> +abstime2tm(AbsoluteTime _time, int *tzp, struct tm * tm, char *tzn)
>  {
> +       time_t time = (time_t) _time;
>  #ifdef USE_POSIX_TIME
>         struct tm  *tx;
> 
> 


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

  22. Linux/Alpha Regression Test Patch (Was Re: Call for port testing on fmgr changes -- Results! )

    Ryan Kirkpatrick <pgsql@rkirkpat.net> — 2000-07-05T01:42:06Z

    On Sun, 25 Jun 2000, Tom Lane wrote:

> > and
> > with this patch applied all regression tests pass just fine (save for
> > geometry of course with its standard off by one in nth decimal place
> > difference).
> 
> Probably we should write that off as a platform issue and create an
> Alpha-specific expected-output file for geometry.  See the documentation
> about platform-specific files, and please send along a patch to add one.

	The patch is attached, just adds a line to the resultmap file as
the geometry-solaris-precision.out file matched the Linux/Alpha output.
Also, the geometry-cygwin-precision.out is an exact match to the
geometry-solaris-precision.out file if anyone is interested in reducing
the number of geometry files. :)
	Now, all regression tests are passing (snapshot from 2000/7/1),
and this is on a build of pgsql straight out of the box. Just untarred,
configure (w/linux_alpha template), and a make. So, it looks like we have
finally reached out-of-the-box compatiblity for Linux/Alpha. :) Though I
have heard that some of the optional interfaces, ODBC in particular, are
not compiling on the Linux/Alpha. I guess one's work is never done...
TTYL.

	PS. The 'make runcheck' for the regression tests is quite a nice
way of testing a pgsql build without affecting a current pgsql install.
One gripe, it calls 'gmake' to do the temporary install, which does not
exists, at least under Debian 2.1 Linux, as GNU make is the only make
installed. Maybe, test for gmake, if it not found, just use make, or use
make outright on linux machines (detected from arch configurations). Just
a suggestion.

	PPS. The snapshots still have a dirty config.cache and
config.status file included with them, requiring a make distclean
immediately after untar.

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------

  23. Re: Linux/Alpha Regression Test Patch (Was Re: Call for port testing on fmgr changes -- Results! )

    Bruce Momjian <pgman@candle.pha.pa.us> — 2000-07-05T04:27:49Z

    Applied.

> On Sun, 25 Jun 2000, Tom Lane wrote:
> 
> > > and
> > > with this patch applied all regression tests pass just fine (save for
> > > geometry of course with its standard off by one in nth decimal place
> > > difference).
> > 
> > Probably we should write that off as a platform issue and create an
> > Alpha-specific expected-output file for geometry.  See the documentation
> > about platform-specific files, and please send along a patch to add one.
> 
> 	The patch is attached, just adds a line to the resultmap file as
> the geometry-solaris-precision.out file matched the Linux/Alpha output.
> Also, the geometry-cygwin-precision.out is an exact match to the
> geometry-solaris-precision.out file if anyone is interested in reducing
> the number of geometry files. :)


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

  24. Re: [HACKERS] Linux/Alpha Regression Test Patch

    Ryan Kirkpatrick <pgsql@rkirkpat.net> — 2000-08-16T02:49:55Z

    On Wed, 5 Jul 2000, Bruce Momjian wrote:

> Applied.
> 
> > 	The patch is attached, just adds a line to the resultmap file as
> > the geometry-solaris-precision.out file matched the Linux/Alpha output.
> > Also, the geometry-cygwin-precision.out is an exact match to the
> > geometry-solaris-precision.out file if anyone is interested in reducing
> > the number of geometry files. :)

	Verified as valid. I downloaded today's snapshot, built it, and
then ran the regression checks (make runcheck). I made no modifications to
the source tree (i.e. no patches), and all regression tests passed. I
think at this point we can declare that pgsql works out of the box on
Linux/Alpha. :)
	I will of course periodically check the snapshots to make sure
nothing new is broken on the Linux/Alpha platform. TTYL.

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------