On Sat, Aug 16, 2014 at 3:28 AM, Noah Misch <n...@leadboat.com> wrote: > Nice algorithm.
Thanks. >> I'd be afraid that a secondary mechanism that mostly-but-not-really >> works could do more harm by allowing us to miss bugs in the primary, >> pipe-based locking mechanism than the good it would accomplish. > > Users do corrupt their NFS- and GFS2-hosted databases today. I would rather > have each process hold only an fcntl() lock than hold only the FIFO file > descriptor. There's no such dichotomy, so let's have both. Meh. We can do that, but I think that will provide us with only the it-works-until-it-doesn't level of protection. Granted, that's more than zero, but does anyone advocate wearing seatbelts for the first 60 minutes you're in the car and then taking them off after that? I think that with a sufficiently long-running server the chances of the lock somehow getting released approach certainty. But I'm not going to fight this one tooth and nail. A bigger question in my view is what to do with the existing mechanism. The main advantage of making a change like this is that we could finally dispense with System V shared memory completely. But we risk encountering systems where the battle-tested System V mechanism works and this new one either fails to work at all (server won't start) or fails to work as desired (interlock broken). So it's tempting to think we should have a GUC or control-file setting to control which mechanism gets used. Of course for QNX, the actual subject of this thread, System V won't be an option, but other people might like a big red button they can push if the new code turns out to be less than we're hoping. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
