That Python code is a huge hunk of workaround kludge. I haven't looked
to see how Postgres configures itself on the glibc2 box, but we should
first check (if you haven't done so already) that it is getting the
right choices for tz configuration.
My recollection is that the two possible Unix-style setups are:
1) use global variables for time zone offsets and names. This can't work
with re-entrant or thread-safe libraries such as glibc2.
2) use variables embedded in the tz structure. I had thought that this
was an older style, but is clearly required for thread-safe code.
We should confirm that our glibc2 machines are being built with option
(2), that they don't implement a third option, and that it is indeed
massively broken. Also, we should characterize under what conditions it
is broken; so far the only case we have is when converting date to
datetime, so the problem may be within that Postgres code rather than a
general problem.
> Regression test passed Ok on datetime, abstime, reltime, tinterval
> tests on Debian 2.0. That is - the error is not triggered. Should we
> change the regression test?
Sure we should. Send patches...
- Tom
