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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2018-09-12T14:00:21Z
Lists: pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> One thing that I can see changing with this patch is how timezone is set
> in postgresql.conf.  For example, on HEAD I get 'Japan' while this patch
> gives back 'Asia/Tokyo'.  Could it be an issue for countries with
> multiple timezones?  I am not sure how Russian systems would react on
> that for example.

Interesting --- what platform were you testing on?

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.  This could only fail to be true if there are
distinct timezones that score_timezone() is failing to tell apart,
which would be a bug in score_timezone, not this patch.  (Presumably,
we could fix any such bug by increasing the number of dates that
score_timezone tests.)

Since the tzdb database is rather full of aliases, for instance the
one you mentioned

$ grep ^Li src/timezone/data/tzdata.zi
...
Li Asia/Tokyo Japan
...

there is certainly plenty of opportunity for this to change the
apparent value of TimeZone.  But I think it's for the better:
instead of choosing an alias that happens to be first according
to some unspecified search order, it will choose the alias that
somebody actually configured the operating system with.

			regards, tom lane


Commits

  1. Attempt to identify system timezone by reading /etc/localtime symlink.

  2. Make sure to run one initdb TAP test with no TZ set

  3. Use one transaction while reading postgres.bki, not one per line.

  4. Move bootstrap-time lookup of regproc OIDs into genbki.pl.