Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>
>> WARNING: could not read time zone file
>> "/home/pgbuild/devel/pginst/share/postgresql/timezonesets/Default": No
>> such file or directory
>>
>
>
>> so it's there but as a msys-virtual path - is that get passed to some
>> win32 function expecting a windows-style path ?
>>
>
> Doh, I see what's the problem: we calculate the sharedir path using
> my_exec_path, and falling back to the hardwired PGSHAREDIR path if
> my_exec_path isn't correct. The problem is that in a Windows
> subprocess, my_exec_path isn't correct until read_backend_variables
> has been done, and *that happens after InitializeGUCOptions* in
> SubPostmasterMain(). So we're trying to set up the tz name data
> before we have the path we need.
>
Is there a reason we have to do things in this order? Could we just
postpone the call to InitializeGUCOptions() for a couple of lines?
If not, then ...
> The reason I didn't notice this in testing with EXEC_BACKEND is that
> I wasn't testing in a relocated installation, and so the fallback
> get_share_path calculation got the right answer anyway.
>
> Not sure about a clean fix. Probably we'll have to do something
> similar to the way TimeZone is handled, where we don't try to read
> in the data until later on in the initialization sequence.
>
>
>
I guess we'd need to set a flag that would postpone reading the data
just during the startup phase, but have it called immediately in all
other cases.
cheers
andrew
