Re: POSIX shared memory redux

On Apr 13, 2011, at 11:37 PM, Tom Lane wrote:

> "A.M." <agentm(at)themactionfaction(dot)com> writes:
>> 1. As long one keeps SysV shared memory around, the postgresql project
>> has to maintain the annoying platform-specific document on how to
>> configure the poorly named kernel parameters.
>
> No, if it's just a small area, I don't see that that's an issue.
> You're going to max out on other things (like I/O bandwidth) long before
> you run into the limit on how many postmasters you can have from this.
> The reason that those parameters are problematic now is that people tend
> to want *large* shmem segments and the typical defaults aren't friendly
> to that.

That's assuming that no other processes on the system are using up the available segments (such as older postgresql instances).

>> 2. My patch proves that SysV is wholly unnecessary. Are you attached to it? (Pun intended.)
>
> You were losing this argument already, but ad hominem attacks are pretty
> much guaranteed to get people to tune you out.

I apologized to Robert Haas in another post- no offense was intended.

> There are real,
> substantive, unfixable reasons to not trust fcntl locking completely.

...on NFS which the postgresql community doesn't recommend anyway. But even in that case, the existing lock file (even without the fcntl lock), can catch that case via the PID in the file contents. That is what I meant when I claimed that the behavior remains the same.

>
>> I would encourage you to take a look at the patch.
>
> Just to be perfectly clear: I have not read your patch, and am not
> likely to before the next commitfest starts, because I have
> approximately forty times too many things to do already. I'm just going
> off your own abbreviated description of the patch. But from what I know
> about fcntl locking, it's not a sufficient substitute for the SysV shmem
> interlock, because it has failure modes that the SysV interlock doesn't,
> and those failure modes occur in real-world cases. Yeah, it'd be nice
> to also be able to lock against other postmasters on other NFS clients,
> but we hardly ever hear of somebody getting burnt by the lack of that
> (and fcntl wouldn't be a bulletproof defense anyway). On the other
> hand, accidentally trying to start a duplicate postmaster on the same
> machine is an everyday occurrence.

I really do appreciate the time you have put into feedback. I posed this question also to Robert Haas: is there a different API which you would find acceptable? I chose fcntl because it seemed well-suited for this task, but the feedback has been regarding NFS v<4 concerns.

Cheers,
M