Thread: Re: REPOST: InitDB Failure on install

>>> creating template1 database in F:/PostgreSQL/data/base/1
>... WARNING:
>>> could
>>> not find a match for Windows timezone "Hora oficial do Brasil"
>>> FATAL:  could not create shared memory segment: No error
>>> DETAIL:  Failed system call was shmget(key=1, size=1196032, 03600).
>> child process was terminated by signal 1
>
>> This is not an issue with the timezone code, this is an
>issue with the
>> shmem code.
>
>Well, the report does also expose a timezone problem, which we've seen
>reported by other people too: apparently strftime can return
>non-English
>names for timezones.  If we want to stick with the current scheme for
>detecting Windows timezone, we may have to use a far larger and uglier
>mapping table than we have now :-(.  Any ideas about that?  Is there
>a way to temporarily force strftime to speak English?  Or maybe another
>API besides strftime?

Oh, right. That's a different issue, and not what's killing his initdb.
But should be fixed anyway, yes.

Hmm. There is GetTimeZoneInformation(). It returns a name, but my guess
is strftime just uses that one so it'll return the same thing.

I'll install a non-english version in my vmware sometime in the next
couple of days (need to get through that mail backlog) and see if it
gives any help, or if I can find something else (could be something in
that registry key somewhere).


I've been having a lot of problems with locallized versions of Windows
translating stupid things (like the name of the Administrator account..)
in the shell. It could well be that this happens here in the API as
well, but that needs some more investigation.


//Magnus

"Magnus Hagander" <mha@sollentuna.net> writes:
> Hmm. There is GetTimeZoneInformation(). It returns a name, but my guess
> is strftime just uses that one so it'll return the same thing.

Probably.  I did a little googling and was slightly stunned to realize
just how little Windows knows about time zones:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/time_zone_information_str.asp
The above struct is what is passed in by SetTimeZoneInformation, so
evidently there just isn't any semantics beyond that.  Ick.  No wonder
we were getting nowhere with the match-the-behavior approach --- the
system simply hasn't got the capability to deal with the concept that
DST rules have changed over time.

So I'd speculate that indeed there is only one version of the standard
zone name and only one version of the daylight zone name, and in a
localized Windows system it's gonna be the localized name :-(

Could we do anything with looking for a match to the Bias, StandardDate,
and DaylightDate members of TIME_ZONE_INFORMATION, and not examining the
name members at all?  I do not know if that will give us unique matches
or not, but it seems like the only approach that won't result in a
vastly bloated lookup table.

            regards, tom lane