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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: Call for port testing on fmgr changes -- Results!
Дата
Msg-id 9754.961391838@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Call for port testing on fmgr changes -- Results!  (Ryan Kirkpatrick <pgsql@rkirkpat.net>)
Ответы Re: Re: Call for port testing on fmgr changes -- Results!  (Ryan Kirkpatrick <pgsql@rkirkpat.net>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Big 7.1 open items
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PROBLEM on SOLARIS