On Sat, Nov 16, 2019 at 7:13 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:Palle Girgensohn <girgen@xxxxxxxxxxxx> writes:
15 nov. 2019 kl. 21:32 skrev Thomas Munro <thomas.munro@xxxxxxxxx>:
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 olderPostgreSQL releases so that people doing minor version upgrades areinconvenienced 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
|
