Tom, I appreciate your patience and explanation. (I am new to PostgreSQL hacking. I have read many old posts but not all of it sticks, sorry). I know QNX support is not high on your TODO list, so I am trying to keep the effort moving without being a distraction.
Couldn't backend "random code" corrupt any file in the PGDATA dir? Perhaps the new fcntl lock file could be kept outside PGDATA directory tree to make likelihood of backend "random code" interference remote. This could be present and used only on systems without System V shared memory (QNX), leaving existing platforms unaffected. I know this falls short of perfect, but perhaps is good enough to get the QNX port off the ground. I would rather have a QNX port with reasonable restrictions than no port at all. Also, I will try to experiment with named pipe locking as Robert had suggested. Thanks again for your feedback, I really do appreciate it. -Keith Baker > -----Original Message----- > From: Tom Lane [mailto:t...@sss.pgh.pa.us] > Sent: Wednesday, August 13, 2014 7:05 PM > To: Baker, Keith [OCDUS Non-J&J] > Cc: Robert Haas; pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] Proposal to add a QNX 6.5 port to PostgreSQL > > "Baker, Keith [OCDUS Non-J&J]" <kbak...@its.jnj.com> writes: > > I assume you guys are working on other priorities, so I did some locking > experiments on QNX. > > > I know fcntl() locking has downsides, but I think it deserves a second look: > > - it is POSIX, so should be fairly consistent across platforms (at > > least more consistent than lockf and flock) > > - the "accidental" open/close lock release can be easily avoided > > (simply don't add new code which touches the new, unique lock file) > > I guess you didn't read the previous discussion. Asserting that it's "easy to > avoid" an accidental unlock doesn't make it true. In the case of a PG > backend, we have to expect that people will run random code inside, say, > plperlu or plpythonu functions. And it doesn't seem unlikely that someone > might scan the entire PGDATA directory tree as part of, for example, a > backup or archiving operation. If we had full control of everything that ever > happens in a PG backend process then *maybe* we could have adequate > confidence that we'd never lose the lock, but we don't. > > 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
