Re: FATAL: invalid value for parameter "TimeZone" after upgrade from 9.2 to 9.6

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

In response to

Responses

Browse pgsql-admin by date

  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