Tony Caduto <tony_caduto@amsoftwaredesign.com> writes:
> Tom Lane wrote:
>> Are you willing to try strace'ing the postmaster?
> I added the strace line like you said and rebooted, it did display the
> [FAILED] after the reboot.
Thanks for collecting the raw data. The salient events seem to be these:
12:57:52.400888 exec() call
12:57:52.619268 completion(?) of opening shared libraries
12:57:52.657465 first call coming from our own code instead of libraries
12:57:52.902476 begin reading postgresql.conf
12:57:52.915949 done reading postgresql.conf
12:57:52.916191 begin trying to identify system timezone
12:58:01.117869 done identifying system timezone
12:58:01.131798 postmaster.pid created
In short: pg_timezone_initialize() took about 8.2 seconds out of the
total time of 8.73 seconds.
Since pg_timezone_initialize() needs to scan all of the 500-odd files
under postgresql/share/timezone/, it isn't so surprising that it would
take a little bit of time. But 8 seconds seems like a lot. The trace
makes it look like localtime() performs stat("/etc/localtime") on each
call, which is pretty ugly --- I wonder if there isn't some way around
that?
Anyway, the short answer is that pg_timezone_initialize ought to wait
till after we've created postmaster.pid. There's no urgent reason to
do it earlier AFAICS. This also explains why we didn't see a startup
problem in earlier releases --- pg_timezone_initialize didn't exist
before 8.0.
regards, tom lane