"Igor Kovalenko" <[EMAIL PROTECTED]> writes: > What really need to be done is new abstraction layer which would cover SysV > API, POSIX and whatever native APIs are better for BeOS/OS2/Win32. I almost > did it last time...
Yes. I just sent off a proposal for a cleaner semaphore API --- please comment on it. My inclination is to stick with the SysV API for shared memory, however. The "stickiness" is actually not a bad thing for us in the shared memory case, because it allows a new postmaster to detect the situation where old backends are still running: it can see that there is an old shmem segment still present with attached processes. Without that, we have no good defense against the scenario where an old postmaster dumped core leaving backends still running. The backends are fine as long as they are left to finish out their operations, or even killed with whatever degree of prejudice the admin wants. But what we must *not* do is allow a new postmaster to start while the old backends are still running; that would mean two sets of backends running without contact with each other, which would be fatal for data integrity. The SysV API lets us detect that case, but I don't see any equally good way to do it if we are using anonymous shared memory. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly