Copy from/to asymmetry
От | Michael Robinson |
---|---|
Тема | Copy from/to asymmetry |
Дата | |
Msg-id | 200001121821.CAA76248@netrinsics.com обсуждение исходный текст |
Ответы |
Re: [HACKERS] Copy from/to asymmetry
|
Список | pgsql-hackers |
I set my time zone to GMT+8 today (because the "official" timezone prescribed by the FreeBSD timezone database for my location is "CST", which was causing all sorts of other problems elsewhere). Tonight, when I did my nightly data transfer (consisting of "copy to" a bunch of tables and concatenating them together into a "pg_dump" type of script file, copying the file over, and then loading with psql), the backend was very unhappy. Every "copy from" block that contained a date crashed. This was particularly unpleasant, because the script is bracketed within a single transaction block, and each table is emptied ("delete from") before new data is copied in. As a result of the crashes, the transaction aborted, but psql kept on processing away, emptying tables, crashing, and repeat. This was on a soon-to-be production e-commerce server. I was able to recover in a few minutes by manually editing the script file to replace all "GMT+8" with "+0800". Had this happened during an automated transfer on a live system, however, the problem could have been severe. I assume that my backups are similarly corrupted. I looked through dt.c, and ParseDateTime appears to assume that timezones are either strictly alphabetic or of the form "+0000". EncodeDateTime, on the other hand, blindly spits out whatever the operating system gives it from localtime(). It seems to me there are two separate problems: 1. x == datetime_in(datetime_out(x)) should always be true for all validx. 2. psql should exit with an error status if it receives a fatal error from the backend and isatty(0) is false. -Michael Robinson
В списке pgsql-hackers по дате отправления: