Re: [COMMITTERS] pgsql: Make it easy to detach completely from shared memory.
От | Robert Haas |
---|---|
Тема | Re: [COMMITTERS] pgsql: Make it easy to detach completely from shared memory. |
Дата | |
Msg-id | CA+Tgmob3AC47yAXm=p+XrVp=bLz8DVooAQ+-B5rGDE9+TivbsQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Make it easy to detach completely from shared memory. (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: [COMMITTERS] pgsql: Make it easy to detach completely from shared memory.
|
Список | pgsql-hackers |
On Tue, Mar 18, 2014 at 8:41 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > On 18 March 2014 11:59, Robert Haas <rhaas@postgresql.org> wrote: >> Make it easy to detach completely from shared memory. >> >> The new function dsm_detach_all() can be used either by postmaster >> children that don't wish to take any risk of accidentally corrupting >> shared memory; or by forked children of regular backends with >> the same need. This patch also updates the postmaster children that >> already do PGSharedMemoryDetach() to do dsm_detach_all() as well. >> >> Per discussion with Tom Lane. > > I think we need to document exactly why dsm_detach_all() isn't simply > part of PGSharedMemoryDetach() ? > > Having two calls seems like a recipe for error in core and extensions. > > 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. On the other hand, your argument is good, too. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: