Re: BUG #11014: Postgres can be put into an error state by setting invalid timezone.
От | Tom Lane |
---|---|
Тема | Re: BUG #11014: Postgres can be put into an error state by setting invalid timezone. |
Дата | |
Msg-id | 18032.1405994589@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #11014: Postgres can be put into an error state by setting invalid timezone. (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
I wrote: > dgillis@dystillr.com writes: >> postgres=# set timezone='-0400'; >> SET >> postgres=# >> postgres=# show timezone; >> TimeZone >> ---------- >> unknown >> (1 row) >> postgres=# select now(); >> The connection to the server was lost. Attempting reset: Failed. > Oh, hm, looks like it didn't occur to us that pg_tzset could reject > out-of-range input :-(. > Previous versions of PG would allow this, interpreting the GMT offset > as 400 hours. In 9.4, the data is fed to the zic library, which thinks > that the zone offset shouldn't exceed 1 week (168 hours); and we're > not defending against a null result. Hmm ... I had checked that this example doesn't crash pre-9.4, but on closer inspection it turns out that the bug is indeed there pre-9.4. You just need to try specific operations that expect session_timezone to be valid always, eg timeofday(): regression=# set timezone='-0400'; SET regression=# select timeofday(); The connection to the server was lost. Attempting reset: Failed. This was introduced in commit 631dc390f49909a5c8ebd6002cfb2bcee5415a9d, which got back-patched, so it's in all the current releases. Too bad the report didn't come in a few hours earlier, we could've fixed it in this week's releases :-( regards, tom lane
В списке pgsql-bugs по дате отправления: