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

On Fri, Nov 17, 2017 at 9:36 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>
> Ah, gotcha. I believe that the FATAL case occurs if the client tries
> to set an invalid parameter value within the connection startup packet,
> rather than after connecting. But that behavior hasn't changed in
> a long time either. I think what you need to be looking for is a
> client-side change in how/when it sends a desired timezone setting to
> the server.
>

That's what I thought as well. However the only thing that changed
yesterday was upgrading Postgres from 9.2.22 to 9.6.6. The app didn't
change and the Postgres timezone stayed at 'US/Central' as it has been all
year. I'm assuming David Wall had a similar scenario in his 8.3.3-to-9.3.4
upgrade.

In our case the client app was running through Tomcat, and had a setenv.sh
that had "-Duser.timezone=CST". That wasn't causing any known issues until
we upgraded our dev database yesterday, and our pre-prod and prod app
servers have that same setting and are up and running vs 9.2.22 still. As I
said before, we have a workaround/fix (using CST6CDT or just removing that
parameter altogether from the options string), but given that everything
else is the same, I have to believe something changed in how Postgres
handles those connections in 9.3 and beyond. I'm just very curious to know
for certain what that was. I'm sure there's more than a few people on
Postgres <= 9.2 that might hit this when upgrading in the near future (now
that 9.2 is EOL).

Don.

--
Don Seiler
www.seiler.us