Thread: Redhat/glibc and postgre time "bug"
There has been quite a few mails on the misoperation in date values
before the epoc on RH7.3 and pgsql7.2.1 (something with glibc).
Is this bug fixed? If yes: How can I achive this fix?
If not: How can I make postgresql work on RH7.3?
Shouldn't the FAQ mention the issue and a workaround?
If some should be a bit confused: The error appears when operating on
dates before the epoc:
rhklan=> create table test(day date);
CREATE
rhklan=> insert into test values('1969-2-2');
INSERT 824159 1
rhklan=> select age(now(),day) from test;
ERROR: Unable to convert date to tm
Rasmus Resen Amossen wrote:
> There has been quite a few mails on the misoperation in date values
> before the epoc on RH7.3 and pgsql7.2.1 (something with glibc).
>
> Is this bug fixed? If yes: How can I achive this fix?
No, no fix yet. We had hoped that since May glibc folks would have
addressed it, but it seems not. We are left working around it
ourselves.
> If not: How can I make postgresql work on RH7.3?
You need a patch which we will have to develop.
>
> Shouldn't the FAQ mention the issue and a workaround?
No, we are not in the habit of making an FAQ entry when every vendor
decides to ship broken software. It takes a lot of requests to make an
FAQ.
> If some should be a bit confused: The error appears when operating on
> dates before the epoc:
>
> rhklan=> create table test(day date);
> CREATE
> rhklan=> insert into test values('1969-2-2');
> INSERT 824159 1
> rhklan=> select age(now(),day) from test;
> ERROR: Unable to convert date to tm
Yep, thread of discussion is:
http://fts.postgresql.org/db/mw/index.html?section=-1&word=Redhat+7.3+time+manipulation+bug&action=Search&sdb_d=7&sdb_m=5&sdb_y=2002&sde_d=8&sde_m=7&sde_y=2002&weight=0&format=0&order=1
I am not in favor of shipping a timezone database with PostgreSQL, and
even if we did, it wouldn't match the OS's database. I think a good
solution is to gab mktime() from glibc, fix the bug, add that code to
our sourcetree (is LGPL) and put the fixed version earlier in the link
line so it is used instead of glibc's mktime.
As you can imagine, it is kind of a strange thing to do, so we are not
rushing to do it, but such a solution may be required soon.
Right now, the only solution I have for you it to complain to your
vendor about mktime in glibc and get a fix from them.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Monday 08 July 2002 02:08 pm, Bruce Momjian wrote: > Rasmus Resen Amossen wrote: > > There has been quite a few mails on the misoperation in date values > > before the epoc on RH7.3 and pgsql7.2.1 (something with glibc). > No, no fix yet. We had hoped that since May glibc folks would have > addressed it, but it seems not. We are left working around it > ourselves. The glibc people do not consider this a bug in mktime(3), as they are following the patently broken 'standard'. Red Hat 7.3 included portions of a prerelease glibc -- patched in to place, and not the official glibc that could be downloaded. Red Hat also does not consider mktime(3) to now be broken. Having said that, a patch for this exists in the current Rawhide. I am loath to include such in an 'official' RPMset for many reasons. Can configure simply test for a 'standard' mktime(3) (standard = broken) for ANY target, and set options accordingly? This would simplify things -- there are a few other systems with this behavior. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen wrote: > On Monday 08 July 2002 02:08 pm, Bruce Momjian wrote: > > Rasmus Resen Amossen wrote: > > > There has been quite a few mails on the misoperation in date values > > > before the epoc on RH7.3 and pgsql7.2.1 (something with glibc). > > > No, no fix yet. We had hoped that since May glibc folks would have > > addressed it, but it seems not. We are left working around it > > ourselves. > > The glibc people do not consider this a bug in mktime(3), as they are > following the patently broken 'standard'. Red Hat 7.3 included portions of a > prerelease glibc -- patched in to place, and not the official glibc that > could be downloaded. > > Red Hat also does not consider mktime(3) to now be broken. That is their opinion, of course. > Having said that, a patch for this exists in the current Rawhide. I am loath > to include such in an 'official' RPMset for many reasons. OK, what does that mean? That there is a fix coming in a future release? I don't know what Rawhide is. > Can configure simply test for a 'standard' mktime(3) (standard = broken) for > ANY target, and set options accordingly? This would simplify things -- there > are a few other systems with this behavior. Yes, we can test for it in configure. Do you want the place-our-own-mktime-first-in-the-link-path option to be enabled in such cases? If so, I need a copy of a fixed mktime for replacement. I also need confirmation that it is LGPL and that it is legally safe for us to included it in our tree, though ODBC is already LGPL but is not linked into the backend. And finally, do we generate a 7.2.2 to fix this, distribute a patch, or wait for 7.3? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Tuesday 09 July 2002 11:39 am, Bruce Momjian wrote: > Lamar Owen wrote: > > Red Hat also does not consider mktime(3) to now be broken. > That is their opinion, of course. Yes, it is. But they're not budging on this one. > > Having said that, a patch for this exists in the current Rawhide. I am > > loath to include such in an 'official' RPMset for many reasons. > OK, what does that mean? That there is a fix coming in a future > release? I don't know what Rawhide is. I'm sorry -- Red Hat talking I am. 'Rawhide' is Red Hat's 'not ready for prime time super-duper testbed' distribution. Cutting edge things, development work, etc, get put there. A look at Rawhide is a look at what the next release of Red Hat Linux might bear some passing resemblance to. At least it has been that way in the past. The Rawhide distribution is available anywhere ftp.redhat.com is mirrored. Of course, as Red Hat has stated many times, "Rawhide might or might not install, work, compile, build, not trash your data, etc. You have been warned... :-)" (paraphrase). The patch is a one-liner to src/include/port/linux.h adding the line: #define NO_MKTIME_BEFORE_1970 This basically kills timezones prior to 1970 for Linux. We will either have to give up the pre-1970 timezones or figure out how to get consistent results without the glibc mktime(3). I don't agree with doing this -- but that portion of it is out of my hands. As to what to do with this information....well, I don't know. I believe mktime(3) is broken -- yet the ISO standards say otherwise. Just because it has always been done that way -- does that trump an official standards body? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen wrote: > On Tuesday 09 July 2002 11:39 am, Bruce Momjian wrote: > > Lamar Owen wrote: > > > Red Hat also does not consider mktime(3) to now be broken. > > > That is their opinion, of course. > > Yes, it is. But they're not budging on this one. > > > > Having said that, a patch for this exists in the current Rawhide. I am > > > loath to include such in an 'official' RPMset for many reasons. > > > OK, what does that mean? That there is a fix coming in a future > > release? I don't know what Rawhide is. > > I'm sorry -- Red Hat talking I am. Well, Red Hat DB is going to look a little silly if it doesn't work on pre-1970 dates. Will Red Hat keep the pre-1970 timezone database info? Is there another way of accessing that info without mktime(). Will putting a corrected mktime early in the link path fix it? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026