On Tue, Jun 26, 2012 at 6:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> So, what about keeping a FIFO in the data directory? > > Hm, does that work if the data directory is on NFS? Or some other weird > not-really-Unix file system?
I would expect NFS to work in general. We could test that. Of course, it's more than possible that there's some bizarre device out there that purports to be NFS but doesn't actually support mkfifo. It's difficult to prove a negative. >> When the >> postmaster starts up, it tries to open the file with O_NONBLOCK | >> O_WRONLY (or O_NDELAY | O_WRONLY, if the platform has O_NDELAY rather >> than O_NONBLOCK). If that succeeds, it bails out. If it fails with >> anything other than ENXIO, it bails out. If it fails with exactly >> ENXIO, then it opens the pipe with O_RDONLY > > ... race condition here ... Oh, if someone tries to start two postmasters at the same time? Hmm. >> and arranges to pass the >> file descriptor down to all of its children, so that a subsequent open >> will fail if it or any of its children are still alive. > > This might be made to work, but that doesn't sound quite right in > detail. > > I remember we speculated about using an fcntl lock on some file in the > data directory, but that fails because child processes don't inherit > fcntl locks. > > In the modern world, it'd be really a step forward if the lock mechanism > worked on shared storage, ie a data directory on NFS or similar could be > locked against all comers not just those on the same node as the > original postmaster. I don't know how to do that though. Well, I think that in theory that DOES work. But I also think it's often misconfigured. Which could also be said of NFS in general. > In the meantime, insisting that we solve this problem before we do > anything is a good recipe for ensuring that nothing happens, just > like it hasn't happened for the last half dozen years. (I see Alvaro > just made the same point.) Agreed all around. -- 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
