On Fri, Nov 17, 2017 at 9:36 AM, Tom Lane <tgl@sss.pgh.pa.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).
