> 16 nov. 2019 kl. 23:06 skrev Thomas Munro <thomas.mu...@gmail.com>: > > On Sat, Nov 16, 2019 at 7:13 PM Tom Lane <t...@sss.pgh.pa.us > <mailto: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?
That could be a way, yes. Any thoughts on this from others following this thread? Palle
