Re: [COMMITTERS] pgsql: Make it easy to detach completely from shared memory.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <rhaas(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Make it easy to detach completely from shared memory.
Date: 2014-03-18 13:51:42
Message-ID: 31745.1395150702@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Mar 18, 2014 at 8:41 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> Perhaps we should consider a parameter for PGSharedMemoryDetach() ?

> Yeah, maybe. It seems like a possible modularity violation, because
> the PGSharedMemory... stuff has heretofore not needed to know anything
> about DSM, and apart from this one function, it still wouldn't.

That was exactly the reason we rejected that design upthread.
PGSharedMemoryDetach is specific to the main shmem segment, and in fact
has multiple OS-dependent implementations.

You could make an argument for inventing some new wrapper function that
calls both PGSharedMemoryDetach and dsm_detach_all, but I don't believe
that the existing flavors of that function should know about DSM.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Simon Riggs 2014-03-18 14:00:34 Re: [COMMITTERS] pgsql: Make it easy to detach completely from shared memory.
Previous Message Robert Haas 2014-03-18 13:09:08 Re: [COMMITTERS] pgsql: Make it easy to detach completely from shared memory.

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-03-18 13:56:08 Re: pg_archivecleanup bug
Previous Message Magnus Hagander 2014-03-18 13:46:59 Re: pg_basebackup --slot=SLOTNAME -X stream