Re: [HACKERS] handling 64bit time_t's
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] handling 64bit time_t's |
Дата | |
Msg-id | 36AD31F7.3B2FE98E@alumni.caltech.edu обсуждение исходный текст |
Ответ на | handling 64bit time_t's (Adrian Gartland <ade@oregan.net>) |
Список | pgsql-hackers |
> I've been looking at fixing the the timestamp problem on the alpha. > I can get it working but I'm wondering if there is any particular > reason that postgres is currently being limited to 2038 as being > the top year. > define UTIME_MAXYEAR (2038) > As you probably know....time_t (a long) on the alpha is a 64 bit > value, so it can cope with dates waaaaaay into the future. > The problem currently breaking the timestamps on the alpha boils > down to > #define AbsoluteTimeIsReal(time) \ > ((bool) (((AbsoluteTime) time) < NOEND_ABSTIME && \ > ((AbsoluteTime) time) > NOSTART_ABSTIME)) > > returning false cause "time" after being propriately cast around > is always returning a value < NOSTART_ABSTIME which > was defined as > #define NOSTART_ABSTIME ((AbsoluteTime) 0x80000001) > I changed AbosoluteTime to be a time_t instead of a int32... > which I'm wondering whether this is a good idea now. I'm a bit slow. If the Alpha's time is read back as signed 8 bytes, but is then coerced to AbsoluteTime as signed 4 bytes, then why would this comparison fail? Though if things aren't 4 bytes at this stage and the 0x80000001 is a large positive integer in 2038 then the comparison fails as you say. > The long an short of it... > I can get it working..changing a number of stuff to time_ts from > int32...this has no effect on any 32bit machines as they are the > same bitsize. > I can get it working (well..i think it was working) so that epoch=0 > infinity=infinty 'now' is the time of the transaction. > or > Have a nightmare of a time trying to workout how to extend the > available time-range. I have tried that...and it all seems to be > working bar I cannot get >2038 due to other code in the proggy. The problem is that abstime is stored in all of the database tables in some system fields, specifically as 4 bytes (the length is defined in pg_type). I'm not sure how to make something this fundamental have a platform-specific length. My solution (at least for now) would be to make sure it becomes a 4 byte quantity just after the call to time() and before calls to localtime(). Look for all instances in src/backend/utils/adt/*.c. Not sure at the moment what else might need looking at. - Tom
В списке pgsql-hackers по дате отправления: