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 <[EMAIL PROTECTED]> 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


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
      choose an index scan if your joining column's datatypes do not
      match

Reply via email to