On Sat, Nov 16, 2019 at 7:13 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Palle Girgensohn <gir...@pingpong.net> writes: > > 15 nov. 2019 kl. 21:32 skrev Thomas Munro <thomas.mu...@gmail.com>: > >> Ugh. It doesn't have the old backward compatibility names like > >> US/Pacific installed by default, which is a problem if that's what > >> initdb picked for your cluster (or you've stored references to any of > >> those names in other ways). > > > One quick fix is to revert the change. Tom thinks this is not reason to > > revert. Would it be enough to edit the postgresql.conf to use the correct > > "modern" name for US/Pacific (PST?)? In rhar case, an update note might be > > sufficient? > > I think the "official" name of that zone is America/Los_Angeles. > But initdb might seize on the US/Pacific alias, if available, > because it's shorter. We've seen related problems with other > time zone names, though usually it was just cosmetic and not a > reason for the postmaster to fail to start. > > Yes, changing the zone name in postgresql.conf should be a sufficient > fix. In theory, a FreeBSD user ought to know the "official" alias > for their zone, since the rest of the system would expect that. > So this is slightly tedious if initdb chose a non-official alias, > but I don't think it's reason to panic.
Perhaps the best thing would be to revert this for the older PostgreSQL releases so that people doing minor version upgrades are inconvenienced by a system that can't start up after "pkg upgrade", but do it for 12 since not many people will be using that yet?
