On 04/15/2017 12:07 AM, Tom Lane wrote:
> Andreas Karlsson <andreas@proxel.se> writes:
>> Looked some at this and what take time now for me seems to mainly be
>> these four things (out of a total runtime of 560 ms).
>> 1. setup_conversion: 140 ms
>> 2. select_default_timezone: 90 ms
>> 3. bootstrap_template1: 80 ms
>> 4. setup_schema: 65 ms
> FWIW, you can bypass select_default_timezone by setting environment
> variable TZ to a valid timezone name before calling initdb. On
> my workstation, that currently cuts the time for "initdb --no-sync"
> from about 1.25 sec to just about exactly 1.0 sec.
>
> I doubt that we want all the buildfarm members to switch over to
> doing that, since then we'd lose coverage of select_default_timezone.
> But it's interesting to speculate about having the buildfarm script
> extract the selected timezone name out of postgresql.conf after the
> first initdb it does, and then set TZ for remaining tests. We surely
> don't need to test select_default_timezone more than once per
> buildfarm run.
>
>
Yeah. The obvious place to do this would be the "make check" stage,
which runs very early. Unfortunately, pg_regress carefully removes its
data directory on success - kind of a pity that's not switchable.
Probably for now the simplest thing for buildfarm animals whose owners
are trying to squeeze every last second would be to put something like
TZ => 'Us/Eastern',
in the build_env section of the config file. But as you say we don't
want everyone doing that.
Alternatively, we could have an initdb TAP test that explicitly removed
the environment setting so we'd get coverage of select_default_timezone,
and have the buildfarm set TZ to something if it's not already set.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services