| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: POSIX shared memory redux |
| Date: | 2011-04-11 22:06:19 |
| Message-ID: | BANLkTikWFAi10EaXVAhWPovLmq_D4QGjWg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Apr 10, 2011 at 5:03 PM, A.M. <agentm(at)themactionfaction(dot)com> wrote:
> To ensure that no two postmasters can startup in the same data directory, I use fcntl range locking on the data directory lock file, which also works properly on (properly configured) NFS volumes. Whenever a postmaster or postmaster child starts, it acquires a read (non-exclusive) lock on the data directory's lock file. When a new postmaster starts, it queries if anything would block a write (exclusive) lock on the lock file which returns a lock-holding PID in the case when other postgresql processes are running.
This seems a lot leakier than what we do now (imagine, for example,
shared storage) and I'm not sure what the advantage is. I was
imagining keeping some portion of the data in sysv shm, and moving the
big stuff to a POSIX shm that would operate alongside it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | A.M. | 2011-04-11 22:11:04 | Re: POSIX shared memory redux |
| Previous Message | Alvaro Herrera | 2011-04-11 21:30:53 | Re: Locking when concurrent updated of foreign references |