Re: Dynamic Shared Memory stuff

On Thu, Dec 05, 2013 at 06:12:48PM +0200, Heikki Linnakangas wrote:
> On 11/20/2013 09:58 PM, Robert Haas wrote:
>> On Wed, Nov 20, 2013 at 8:32 AM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
>>> * As discussed in the "Something fishy happening on frogmouth" thread, I
>>> don't like the fact that the dynamic shared memory segments will be
>>> permanently leaked if you kill -9 postmaster and destroy the data directory.
>>
>> Your test elicited different behavior for the dsm code vs. the main
>> shared memory segment because it involved running a new postmaster
>> with a different data directory but the same port number on the same
>> machine, and expecting that that new - and completely unrelated -
>> postmaster would clean up the resources left behind by the old,
>> now-destroyed cluster.  I tend to view that as a defect in your test
>> case more than anything else, but as I suggested previously, we could
>> potentially change the code to use something like 1000000 + (port *
>> 100) with a forward search for the control segment identifier, instead
>> of using a state file, mimicking the behavior of the main shared
>> memory segment.  I'm not sure we ever reached consensus on whether
>> that was overall better than what we have now.
>
> I really think we need to do something about it. To use your earlier  
> example of parallel sort, it's not acceptable to permanently leak a 512  
> GB segment on a system with 1 TB of RAM.

I don't.  Erasing your data directory after an unclean shutdown voids any
expectations for a thorough, automatic release of system resources.  Don't do
that.  The next time some new use of a persistent resource violates your hope
for this scenario, there may be no remedy.

Having said that, I'm not opposed to storing the DSM control segment handle in
PGShmemHeader, which would enable DSM cleanup whenever we find cause to
reclaim a main sysv segment.

> One idea is to create the shared memory object with shm_open, and wait  
> until all the worker processes that need it have attached to it. Then,  
> shm_unlink() it, before using it for anything. That way the segment will  
> be automatically released once all the processes close() it, or die. In  
> particular, kill -9 will release it. (This is a variant of my earlier  
> idea to create a small number of anonymous shared memory file  
> descriptors in postmaster startup with shm_open(), and pass them down to  
> child processes with fork()). I think you could use that approach with  
> SysV shared memory as well, by destroying the segment with  
> sgmget(IPC_RMID) immediately after all processes have attached to it.

That leaves a window in which we still leak the segment, and it is less
general: not every use of DSM is conducive to having all processes attach in a
short span of time.

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com