Re: [PORTS] Linux/Alpha Regression tests....
От | Thomas G. Lockhart |
---|---|
Тема | Re: [PORTS] Linux/Alpha Regression tests.... |
Дата | |
Msg-id | 363A84E9.2DA479C9@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Linux/Alpha Regression tests.... (Ryan Kirkpatrick <rkirkpat@nag.cs.colorado.edu>) |
Список | pgsql-hackers |
> The biggest trouble in finding this bug is how "complex" the > datetime code is... Actually after hacking at it for a few hours (with > no success) I have other words to describe it, but I will refrain. I'll assume it would be a compliment :) I was happy with how simple I was able to make the code. Date/time stuff ain't easy. I'm guessing that the problem is in one of two areas: 1) the configure/build process is confused as to what kind of time support you have on your system. There are two styles of local time conversion interfaces on Unix systems: one which uses global variables to return info on time zones, and one which returns that info as part of the tz structure. The third type, which is pretty much no timezone support, is probably not relevant, though if your system is really confused you should eliminate that as a possibility. The second type is reentrant, the first is not. It doesn't really matter which kind your system uses because each backend is essentially single-threaded, but if it guesses wrong on what kind of system you have then the results will be garbage. 2) the Postgres code stomps on the global variables used for timezone info. I think I got that resolved, but I figured I should mention it just in case. It is most likely that (1) is the problem. Try compiling with "-DDATEDEBUG" specified, and see if that helps you track through the code. Though it seems like you already know where the problem is located, so I'd just pound on an example until you get it figured out. Good luck. - Tom
В списке pgsql-hackers по дате отправления: