Re: LWLock/ShmemIndex startup question
От | Tom Lane |
---|---|
Тема | Re: LWLock/ShmemIndex startup question |
Дата | |
Msg-id | 8335.1073972667@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: LWLock/ShmemIndex startup question (Claudio Natoli <claudio.natoli@memetrics.com>) |
Ответы |
Re: LWLock/ShmemIndex startup question
|
Список | 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 по дате отправления: