Re: Posix Shared Mem patch
От | Robert Haas |
---|---|
Тема | Re: Posix Shared Mem patch |
Дата | |
Msg-id | CA+TgmoauPcoiEFknRtBckFWi8-sudeDYZSHfG+ALSd-he_svUQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Posix Shared Mem patch (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Posix Shared Mem patch
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-hackers |
On Tue, Jun 26, 2012 at 5:44 PM, Josh Berkus <josh@agliodbs.com> wrote: > >> On that, I used to be of the opinion that this is a good compromise (a >> small amount of interlock space, plus mostly posix shmem), but I've >> heard since then (I think via AgentM indirectly, but I'm not sure) >> that there are cases where even the small SysV segment can cause >> problems -- notably when other software tweaks shared memory settings >> on behalf of a user, but only leaves just-enough for the software >> being installed. This is most likely on platforms that don't have a >> high SysV shmem limit by default, so installers all feel the >> prerogative to increase the limit, but there's no great answer for how >> to compose a series of such installations. It only takes one >> installer that says "whatever, I'm just catenating stuff to >> sysctl.conf that works for me" to sabotage Postgres' ability to start. > > Personally, I see this as rather an extreme case, and aside from AgentM > himself, have never run into it before. Certainly it would be useful to > not need SysV RAM at all, but it's more important to get a working patch > for 9.3. +1. I'd sort of given up on finding a solution that doesn't involve system V shmem anyway, but now that I think about it... what about using a FIFO? The man page for open on MacOS X says: [ENXIO] O_NONBLOCK and O_WRONLY are set, the file is a FIFO, and no process has it openfor reading. And Linux says: ENXIO O_NONBLOCK | O_WRONLY is set, the named file is a FIFO and no process has the file open for reading. Or, the file is a device special file and no corresponding device exists. And HP/UX says: [ENXIO] O_NDELAY is set, the named file is a FIFO, O_WRONLY is set, and no processhas the file open for reading. So, what about keeping a FIFO in the data directory? When the postmaster starts up, it tries to open the file with O_NONBLOCK | O_WRONLY (or O_NDELAY | O_WRONLY, if the platform has O_NDELAY rather than O_NONBLOCK). If that succeeds, it bails out. If it fails with anything other than ENXIO, it bails out. If it fails with exactly ENXIO, then it opens the pipe with O_RDONLY and arranges to pass the file descriptor down to all of its children, so that a subsequent open will fail if it or any of its children are still alive. This might even be more reliable than what we do right now, because our current system appears not to be robust against the removal of postmaster.pid. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: