where to put NO_MKTIME_BEFORE_1970?

I'm running Red Hat 7.3 at home. For the fun of it, I put:
#define NO_MKTIME_BEFORE_1970

into /src/include/port/linux.h and then did:
make clean
make all
make install
initdb
make installcheck

But I'm still getting the < 1970 regression test failures. What else do
I need to do?

Joe

Joe Conway <mail(at)joeconway(dot)com> writes:
> I'm running Red Hat 7.3 at home. For the fun of it, I put:
> #define NO_MKTIME_BEFORE_1970
> But I'm still getting the < 1970 regression test failures. What else do
> I need to do?

I'd assume you need to select different regression comparison file(s)
in src/test/regress/resultmap - probably horology-no-DST-before-1970.

regards, tom lane

Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>
>>I'm running Red Hat 7.3 at home. For the fun of it, I put:
>> #define NO_MKTIME_BEFORE_1970
>>But I'm still getting the < 1970 regression test failures. What else do
>>I need to do?
>
>
> I'd assume you need to select different regression comparison file(s)
> in src/test/regress/resultmap - probably horology-no-DST-before-1970.
>

<slaps head>I guess that makes perfect sense!

Is /src/include/port/linux.h the correct place to put this or should
something more specific to Red Hat 7.3 be used (and if so, any ideas
about how to detect that Red Hat 7.3 is being used)?

Thanks,

Joe

Joe Conway <mail(at)joeconway(dot)com> writes:
> Is /src/include/port/linux.h the correct place to put this or should
> something more specific to Red Hat 7.3 be used (and if so, any ideas
> about how to detect that Red Hat 7.3 is being used)?

Really what we need is a test on the glibc version, which seems a
bit difficult. I am half inclined to put in a configure test that
actually checks whether mktime will work on pre-1970 dates ... but
I dunno if Peter will hold still for that. In any case we don't
currently have a mechanism for reflecting whatever configure would
discover into the resultmap.

regards, tom lane

Tom Lane writes:

> Really what we need is a test on the glibc version, which seems a
> bit difficult.

Well, it's not that difficult to figure out the version (run
/lib/libc.so.6), but I'm afraid the version is not going to tell you
anything. For instance, the libc versions that are claimed to have the
problem in Red Hat releases don't appear to have that problem here.

> In any case we don't currently have a mechanism for reflecting whatever
> configure would discover into the resultmap.

That would appear to be very tricky. Maybe we need to misappropriate the
alternate result file mechanism that was intended for the locale
differences.

--
Peter Eisentraut peter_e(at)gmx(dot)net