pgsql: Make it easy to detach completely from shared memory.
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.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/79a4d24f31e09eb3c421deb34829eee0bf6acd67
Modified Files
--------------
src/backend/postmaster/pgarch.c | 2 ++
src/backend/postmaster/pgstat.c | 2 ++
src/backend/postmaster/syslogger.c | 2 ++
src/backend/storage/ipc/dsm.c | 27 +++++++++++++++++++++++++++
src/include/storage/dsm.h | 1 +
5 files changed, 34 insertions(+)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
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() ?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
On Tue, Mar 18, 2014 at 8:41 AM, Simon Riggs <simon@2ndquadrant.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 18 March 2014 13:51, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Tue, Mar 18, 2014 at 8:41 AM, Simon Riggs <simon@2ndquadrant.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.
I'm not bothered which we choose, as long as its well documented to
ensure people that use those calls don't detach from just one when
they really would wish to detach from both.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers