Re: Posix Shared Mem patch - Mailing list pgsql-hackers

From A.M.
Subject Re: Posix Shared Mem patch
Date
Msg-id 4FEA55BD.4040405@themactionfaction.com
Whole thread Raw
In response to Re: Posix Shared Mem patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Posix Shared Mem patch  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 06/26/2012 07:30 PM, Tom Lane wrote:
> "A.M." <agentm@themactionfaction.com> writes:
>> On Jun 26, 2012, at 6:12 PM, Daniel Farina wrote:
>>> I'm simply suggesting that for additional benefits it may be worth
>>> thinking about getting around nattach and thus SysV shmem, especially
>>> with regard to safety, in an open-ended way.
>
>> I solved this via fcntl locking.
>
> No, you didn't, because fcntl locks aren't inherited by child processes.
> Too bad, because they'd be a great solution otherwise.
>

You claimed this last time and I replied:
http://archives.postgresql.org/pgsql-hackers/2011-04/msg00656.php

"I address this race condition by ensuring that a lock-holding violator 
is the postmaster or a postmaster child. If such as condition is 
detected, the child exits immediately without touching the shared 
memory. POSIX shmem is inherited via file descriptors."

This is possible because the locking API allows one to request which PID 
violates the lock. The child expects the lock to be held and checks that 
the PID is the parent. If the lock is not held, that means that the 
postmaster is dead, so the child exits immediately.

Cheers,
M


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [PATCH 08/16] Introduce the ApplyCache module which can reassemble transactions from a stream of interspersed changes
Next
From: "A.M."
Date:
Subject: Re: Posix Shared Mem patch