Re: HEADS UP: Win32/OS2/BeOS native ports

"Igor Kovalenko" <Igor(dot)Kovalenko(at)motorola(dot)com> 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