Re: POSIX Shared memory, revised, again

Messages with PDF's seem to be dropped as Magnus described yesterday.
It is in this tarball though:
http://homepage.mac.com/cmarcellino/postgres-posix-shmem.tar

As Tom has said a few times, there is an issue with the need to keep
two different lifecycles of postmasters and backends out of the
database.
I was working under the assumption that the OS I was using had a
standard implementation of shm_unlink. Darwin conveniently keeps new
shm_open's from succeeding after a shm_unlink. It turns out that on
platforms other than Darwin/Mac OS X, the patch can't prevent lone
backends from corrupting the db.

The only portable way I can think of that might make this work would
be to use a either a small token SysV segment for mutual exclusion
(as discussed previously), or to use a SysV semaphore with SEM_UNDO
to clean up on process crashes/killings. I need to flesh out the
latter idea. Does anyone have any thoughts on whether this would be
worth trying? We have a strong need in our group to use POSIX shmem
and the more portable and robust it is, the better.

Thanks,
Chris



On Feb 28, 2007, at 9:24 AM, David Fetter wrote:

> On Tue, Feb 27, 2007 at 11:17:44AM -0800, Chris Marcellino wrote:
>> So I've finished reformulating this patch to use the device/inode
>> instead of the hash idea I had earlier.
>>
>> I have tested this patch (on Darwin) to permit the postmaster to
>> recover after a crash or killing, and it will not permit the
>> postmaster to restart while another postmaster or backends are still
>> in the database (regardless of the lockfile status).  The ideas are
>> the same as before, but are described via flowchart in the attached
>> PDF.
>
> The PDF didn't come through.  Could you please re-send?
>
> Cheers,
> David.
> --
> David Fetter <david@fetter.org> http://fetter.org/
> phone: +1 415 235 3778        AIM: dfetter666
>                               Skype: davidfetter
>
> Remember to vote!
> Consider donating to PostgreSQL: http://www.postgresql.org/about/
> donate
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: explain analyze is your friend