Tom, that is a definitely valid point and thanks for the feedback. I
assume that the 'more modern' string segment naming gave the POSIX
methods an edge in avoiding collision between other apps.
As far as detecting a) whether anyone else is currently attached to
that segment and b) whether an earlier existence of the current
backend was still attached to a segment, I presumed that checking the
pid's of the backend that owns the shared memory segment and checking
the data directory (both which the SysV code already does) would
suffice?
What am I forgetting?
Michael, that is an interesting idea. That might be an avenue to
explore if there isn't a simpler way.
Thanks,
Chris Marcellino
On Feb 6, 2007, at 7:51 AM, Michael Paesold wrote:
> Tom Lane wrote:
>> Chris Marcellino <maps@levelview.com> writes:
>>> To this end, I have "ported" the svsv_shmem.c layer to use the
>>> POSIX calls (which are some ways more robust w.r.t reducing
>>> collision by using strings as shared memory id's, instead of ints).
>> This has been suggested before, and rejected before, on the
>> grounds that
>> the POSIX API provides no way to detect whether anyone else is
>> attached
>> to the segment. Not being able to tell that is a tremendous
>> robustness
>> hit for us. We are not going to risk destroying someone's database
>> (or in the alternative, failing to restart after most crashes, which
>> it looks like your patch would do) in order to make installation
>> fractionally easier.
>> I read through your patch in the hopes that you had a solution for
>> this,
>> but all I find is a copied-and-pasted comment
>>> /*
>>> * We detect whether a shared memory segment is in use by seeing
>>> whether
>>> * it (a) exists and (b) has any processes are attached to it.
>>> */
>> followed by code that does no such thing.
>
> Just an idea, but would it be possible to have a small SysV area as
> an "advisory lock" (using the existing semantics) to protect the
> POSIX segment.
>
> Best Regards
> Michael Paesold
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
