Hi,
On 2019-08-01 13:59:11 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > When used and a symlink, could we resolve the symlink when determining
> > the timezone? When loading a timezone in the backend, not during
> > initdb. While that'd leave us with the instability, it'd at least would
> > help clients etc understand what the setting actually means?
>
> The question here is what the string "localtime" means when it's in
> the timezone variable.
Right.
> I guess yes, we could install some show_hook for timezone that goes
> and looks to see if it can resolve what that means. But that sure
> seems to me to be in you've-got-to-be-kidding territory.
Fair enough. I'm mildly worried that people will just carry their
timezone setting from one version's postgresql.conf to the next as they
upgrade.
> Especially since the platforms I've seen that do this tend to use hard
> links, so that it's questionable whether the pushups would accomplish
> anything at all.
Hm, debian's is a symlink (or rather a chain of):
$ ls -l /usr/share/zoneinfo/localtime
lrwxrwxrwx 1 root root 14 Jul 4 14:04 /usr/share/zoneinfo/localtime -> /etc/localtime
$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 39 Jul 15 15:40 /etc/localtime -> /usr/share/zoneinfo/America/Los_Angeles
The system installed versions of postgres I have available all ended up
with timezone=localtime.
Not sure how long they've been symlinks. I randomly accessed a backup of
an older debian installation, from 2014, and there it's a file (with
link count 1).
But presumably upgrading would yield a postgresql.conf that still had
localtime, but localtime becoming a symlink.
Greetings,
Andres Freund