Re: Proposal to add a QNX 6.5 port to PostgreSQL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Baker, Keith [OCDUS Non-J&J]" <KBaker9(at)its(dot)jnj(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal to add a QNX 6.5 port to PostgreSQL
Date: 2014-08-13 23:04:44
Message-ID: 8647.1407971084@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Baker, Keith [OCDUS Non-J&J]" <KBaker9(at)its(dot)jnj(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-08-13 23:45:00 Re: What happened to jsonb's JENTRY_ISFIRST?
Previous Message Tom Lane 2014-08-13 22:47:42 What happened to jsonb's JENTRY_ISFIRST?