Re: date/time compatible problems in 7.2 - Mailing list pgsql-hackers

From Ruslan A Dautkhanov
Subject Re: date/time compatible problems in 7.2
Date
Msg-id 3C7470FA.5C17E04@scn.ru
Whole thread Raw
In response to date/time compatible problems in 7.2  (Ruslan A Dautkhanov <rusland@scn.ru>)
List pgsql-hackers
Thomas Lockhart wrote:

> > I has pg_dump my DB in 7.1.3 and try ro pg_restore it in 7.2
> > version.
> > psql:/.../dbdump/.dbrestore.tmp:1624094: ERROR:  copy: line 1, Bad
> > timestamp external representation 'Fri 25 Jan 23:59:59 2002 KRAT'
> > psql:/.../dbdump/.dbrestore.tmp:1624094: lost synchronization with
> > server, resetting connection
>
> Not sure why it is crashing. But "KRAT" is a time zone not recognized
by
> the PostgreSQL date/time parser. In fact it could be afaik (it is
> mentioned but commented-out in the parser) but it either had a screwy
> definition or I couldn't figure out what the definition was. It could
be
> added for 7.2.1 (and I could send a patch beforehand) if I knew the
> proper definition. Check src/backend/utils/adt/datetime.c and look for

> "krat".
   KRAT,KRAST is timezone code generated by FreeBSD automatically.   You can check up /usr/share/zoneinfo  - it have
alltimezones.   You can see timezones KRAT,KRAST in file   /usr/share/zoneinfo/Asia/Krasnoyarsk.
 
   I already break idea to pg_dump in 7.1.3 and pg_restore in 7.2 and   tried to remove ' KRAT' substring from all my
*.datfiles, created
 
by   pg_dump and change schema to fields without timezone. After I tried   pg_restore only data from dbdump-file, but
pg_restoresays, that   can't initialize header from TOC-file, but I not even touched it.   TOC - is only one binary
filein dbdump-file. I think that it also
 
have   smth like CRC code about all other files, and this is reason why
they   say that can't initialize TOC-file?
   How to patch datetime.c to 7.2 permit my 'KRAT' timezone?


   Greatly appreciate,   Ruslan A Dautkhanov


pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: DateStyle bug
Next
From: Hannu Krosing
Date:
Subject: Re: MySQL/InnoDB benchmarks