>>> 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
