Re: Re: Call for port testing on fmgr changes -- Results! - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: Call for port testing on fmgr changes -- Results!
Date
Msg-id 9754.961391838@sss.pgh.pa.us
Whole thread Raw
In response to Re: Call for port testing on fmgr changes -- Results!  (Ryan Kirkpatrick <pgsql@rkirkpat.net>)
Responses Re: Re: Call for port testing on fmgr changes -- Results!
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Big 7.1 open items
Next
From: Tom Lane
Date:
Subject: Re: PROBLEM on SOLARIS