Re: LWLock/ShmemIndex startup question

Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com> writes:
> Tom Lane writes:
>> I'm not sure there's any need for
>> src/backend/port/win32/sema.c at all.

> (Do you have any idea on the historical
> context of this code? I wondered as to, if we have no win32 port, why there
> would be a seemingly good-to-go sema replacement?)

[cvs is your friend...] It appears to have been added as part of the
MinGW porting work last May. I don't have much faith in it; as far as
I heard the MinGW port never got further than making the client-side
code work, and so this file has no real-world testing.

> No chance on getting the Shmem bootrap rearrangement past you, as described
> in my earlier mail?

I didn't say no chance, I was just questioning the reason. We don't
need a slavish implementation of SysV semaphores. What we need is
something implementing the API defined by src/include/storage/pg_sema.h
for which we presently have two implementations:
src/backend/port/posix_sema.c
src/backend/port/sysv_sema.c
(actually three implementations if you count named and unnamed POSIX
semaphores as different, which you very well could). I'd be inclined
to think that something using Windows-native semaphore primitives to
implement this API is the way to go.

regards, tom lane