"A.M." <age...@themactionfaction.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.
> 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. There are real,
substantive, unfixable reasons to not trust fcntl locking completely.
> 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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
