Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

On Thu, Sep 13, 2018 at 11:20 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael@paquier.xyz> writes:
> > On Wed, Sep 12, 2018 at 10:00:21AM -0400, Tom Lane wrote:
> >> I believe that this patch will never make for any functional change,
> >> it will only give you some other alias for the zone it would have
> >> selected anyway.
>
> > Looking at the list of aliases, I am not seeing listed countries running
> > across multiple timezones, so that may be fine.
>
> Not sure what you're worried about.  "Linked" time zones are the *same
> data*.  In an installed tzdb tree, the Japan file is either a hardlink or
> symlink to the Asia/Tokyo one, so they can't differ.  What you seem to be
> speculating about is actual errors in the tzdb data, ie not describing
> the facts on the ground in particular places.  That's possible I suppose
> but it's hardly our problem if it happens; it'd be theirs to fix.

I tested this on a system where /etc/localtime is not a symlink
(FreeBSD) and it worked fine, falling back to the old behaviour and
finding my timezone.  (Apparently the argument against a symlink
/etc/localtime -> /usr/share/tzinfo/...  is that new processes would
effectively switch timezone after /usr is mounted so your boot logs
would be mixed up.  Or something.  I bet that actually happens on
Linux too, but maybe no one does /usr as a mount point anymore...?)

I noticed that the patch does a bunch of s/Olson/IANA/.  That leaves
only one place in the tree that still refers to the "Olson" database:
dt_common.c.  Might want to change that too?

-- 
Thomas Munro
http://www.enterprisedb.com