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.

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.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Andrew Dunstan <andrew@dunslane.net> writes:
> 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?

Maybe, but I'm disinclined to mess with that. I have a patch that
makes it work like TimeZone, but am having difficulty committing
.... looks like that Polish script kiddie is at it again ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq