"Baker, Keith [OCDUS Non-J&J]" <KBaker9@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,
uniquelock 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