Skip site navigation (1) Skip section navigation (2)

Re: Posix Shared Mem patch

From: "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Posix Shared Mem patch
Date: 2012-06-27 00:37:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 06/26/2012 07:30 PM, Tom Lane wrote:
> "A.M." <agentm(at)themactionfaction(dot)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:

"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.


In response to


pgsql-hackers by date

Next:From: A.M.Date: 2012-06-27 00:40:46
Subject: Re: Posix Shared Mem patch
Previous:From: Andres FreundDate: 2012-06-27 00:13:18
Subject: Re: [PATCH 08/16] Introduce the ApplyCache module which can reassemble transactions from a stream of interspersed changes

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group