Re: AW: AW: AW: Re: tinterval - operator problems on AIX - Mailing list pgsql-hackers

Thomas Lockhart writes:

> I'm not sure I fully appreciate the distinction here. configure will
> check for "behavior" of various kinds, including "behavior assumptions"
> in the PostgreSQL code.

There are two general categories of platform dependencies:  One is
compilation system features, for example presence of certain functions,
libraries, header files, argument types, compiler flags.  These sort of
things must be determined before compilation can begin.  Autoconf is used
to test for these things.

The other category is run-time behaviour, which is the present case of
testing whether mktime() behaves a certain way when given certain
arguments.  Another item that has been thrown around over the years is
whether the system supports Unix domain sockets (essentially a run-time
behaviour check of socket()).  You do not need to check these things in
configure; you can just do it when the program runs and adjust
accordingly.

More importantly, you *should* *not* do these tests in configure because
these tests will be unreliable in a cross-compilation situation.
Cross-compilation in this context does not only mean compiling between
completely different platforms, but it includes any setup where the build
system is configured differently from the system you're going to run the
system on, including building on a noexec file system, misconfigured
run-time linkers, different user id, or just a different file system
layout on an otherwise identical platform.

I'm not making these things up.  Just yesterday there was a message on
this list where someone ran into this problem and his configure run
misbehaved badly.  (PostgreSQL currently violates these rules, but that
does not mean that we should make it harder now to clean it up at some
later date.)  Admittedly, these situations sound somewhat exotic, but that
does not mean they do not happen, it may merely mean that PostgreSQL is
not fit to perform in these situations.

> So the issue for this case is simply whether it is appropriate to check
> for behavior at run time on all platforms, even those known to "never"
> exhibit this problematic result,

You can make the run-time check #ifdef one or the other platform.  Or you
don't check at all and just postulate the misfeature for a set of
platforms.  We have done this in at least two cases:  The list of
platforms known not to support Unix domain sockets (HAVE_UNIX_SOCKETS),
and the list of platforms known to have a peculiar bug in the accept()
implementation (happen to be both from SCO).  I think this is an
appropriate solution in cases where the affected systems can be classified
easily.  But as soon as some versions of some of these systems start
implementing Unix sockets (which is indeed the situation we're currently
facing) or SCO fixes their kernels we're going to have to think harder.

So I would currently suggest that you define

#ifdef AIX || IRIX
# define NO_DST_BEFORE_1970
#endif

but when these systems get fixed you might have to run a simple check once
when the system starts up.  This is not really a "hit".

> Andreas, Pete and I were advocating the latter view: that the majority
> of platforms which happen to be well behaved should run code optimized
> for them, while the bad actors can be supported without "#ifdef __AIX__
> || __IRIX__" in our code, but rather with a more helpful "#ifdef
> NO_DST_BEFORE_1970" or whatever.

Yeah.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/