Re: LWLock/ShmemIndex startup question - Mailing list pgsql-hackers

From Tom Lane
Subject Re: LWLock/ShmemIndex startup question
Date
Msg-id 8335.1073972667@sss.pgh.pa.us
Whole thread Raw
In response to Re: LWLock/ShmemIndex startup question  (Claudio Natoli <claudio.natoli@memetrics.com>)
Responses Re: LWLock/ShmemIndex startup question
List pgsql-hackers
Claudio Natoli <claudio.natoli@memetrics.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.csrc/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


pgsql-hackers by date:

Previous
From: Claudio Natoli
Date:
Subject: Re: LWLock/ShmemIndex startup question
Next
From: Claudio Natoli
Date:
Subject: Re: LWLock/ShmemIndex startup question