From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Don Seiler <don(at)seiler(dot)us> |
Cc: | pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: FATAL: invalid value for parameter "TimeZone" after upgrade from 9.2 to 9.6 |
Date: | 2017-11-17 15:25:11 |
Message-ID: | 22950.1510932311@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Don Seiler <don(at)seiler(dot)us> writes:
> My issue is more or less similar to
> http://www.postgresql-archive.org/Upgrading-from-PG-8-3-3-to-9-3-4-FATAL-invalid-value-for-parameter-quot-TimeZone-quot-quot-PST-quot-td5805665.html
> However what I'm looking to answer is why this wasn't fatal in 9.2?
It was. I don't think PG has ever accepted just "PST" (or "CDT") as a
timezone name. There's no such entry in the IANA tz database, and it's
not a legal POSIX zone specification --- you'd need at least "PST8" for
it to go through that code path. I tried it just now on 7.4.30, which is
the oldest version I have on this machine (about 2 years older than 9.2.0)
and it failed as expected:
regression=# set timezone = 'PST';
ERROR: unrecognized time zone name: "PST"
Now, it's barely conceivable that you strong-armed 9.2 into accepting
it by making a file or symlink named "PST" in the timezone database
directory of the old installation ... but otherwise, I'm quite certain
it would not have taken it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan S. Katz | 2017-11-17 15:29:25 | Re: [ADMIN] Reaching out pgbouncer people, does pgbouncer-general@lists.pgfoundry.org work |
Previous Message | Don Seiler | 2017-11-17 15:07:55 | FATAL: invalid value for parameter "TimeZone" after upgrade from 9.2 to 9.6 |