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
