Re: POSIX shared memory support

Chris Marcellino <cmarcellino@apple.com> writes:
> The System V shared memory facilities provide a method to determine
> who is attached to a shared memory segment.
> This is used to prevent backends that were orphaned by crashed or
> killed database processes from corrupting the data-
> base as it is restarted. The same effect can be achieved with using
> the POSIX APIs,

... except that it can't ...

> but since the POSIX library does not
> have a way to check who is attached to a segment, atomic segment
> creation must be used to ensure exclusive access to
> the database.

How does that fix the problem?  If you can't actually tell whether
someone is attached to an existing segment, then you're still up against
the basic rock-and-a-hard-place issue: either you assume there is no one
there (and corrupt your database if you're wrong) or you assume there is
someone there (and force manual intervention by the DBA to recover after
postmaster crashes).  Neither of these alternatives is really acceptable.

> In order for this to work, the key name used to open and create the
> shared memory segment must be unique for each
> data directory. This is done by using a strong hash of the canonical
> form of the data directory�s pathname.

"Strong hash" is not a guarantee, even if you could promise that you
could get a unique canonical path, which I doubt you can.  In any case
this fails if the DBA decides to rename the directory on the fly (don't
laugh; not only are there instances of that in our archives, there are
people opining that we need to allow it --- even with the postmaster
still running).

> This also re-
> moves any risk of other applications, or other databases� memory
> segments colliding with the current shared memory
> segment, which conveniently simplifies the logic.

How exactly does it remove that risk?  I think you're wishfully-thinking
that if you are creating an unreadable hash value then there will never
be any collisions against someone else with the same touching faith that
*his* unreadable hash values will never collide with anyone else's.
Doesn't give me a lot of comfort.  Not that it matters, since the
approach is broken even if this specific assumption were sustainable.

            regards, tom lane