Hi, On 2019-08-01 13:59:11 -0400, Tom Lane wrote: > Andres Freund <and...@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
