Re: Proposal to add a QNX 6.5 port to PostgreSQL
От | Tom Lane |
---|---|
Тема | Re: Proposal to add a QNX 6.5 port to PostgreSQL |
Дата | |
Msg-id | 8647.1407971084@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Proposal to add a QNX 6.5 port to PostgreSQL ("Baker, Keith [OCDUS Non-J&J]" <KBaker9@its.jnj.com>) |
Ответы |
Re: Proposal to add a QNX 6.5 port to PostgreSQL
|
Список | pgsql-hackers |
"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
В списке pgsql-hackers по дате отправления: