Horton

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

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, John Naylor <jcnaylor@gmail.com>, Andres Freund <andres@anarazel.de>, Andreas Karlsson <andreas@proxel.se>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-05-09T15:09:02Z
Lists: pgsql-hackers 
On Tue, May 8, 2018 at 4:48 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Really the only thing here that jumps out as being unduly expensive for
> what it's doing is select_default_timezone.  That is, and always has been,
> a brute-force algorithm; I wonder if there's a way to do better?  We can
> probably guess that every non-Windows platform is using the IANA timezone
> data these days.  If there were some way to extract the name of the active
> timezone setting directly, we wouldn't have to try to reverse-engineer it.
> But I don't know of any portable way :-(

Who says we need a portable way?  If we had something that worked on
Linux and macOS, it would cover most developer environments.  I wonder
if readlink("/etc/localtime", buf, sz) might be a viable approach.
You could, at least, try any time zone you can derive that way first,
before you try any others.

Also, how about having a --timezone option for initdb?  Then you could
determine the time zone just once and pass it down to subsequent
initdb invocations.  Or just hardcode the regression tests to use some
fixed time zone, like Antarctica/Troll.  :-)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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.