Thread: pgsql: Invent a memory context reset/delete callback mechanism.
Invent a memory context reset/delete callback mechanism. This allows cleanup actions to be registered to be called just before a particular memory context's contents are flushed (either by deletion or MemoryContextReset). The patch in itself has no use-cases for this, but several likely reasons for wanting this exist. In passing, per discussion, rearrange some boolean fields in struct MemoryContextData so as to avoid wasted padding space. For safety, this requires making allowInCritSection's existence unconditional; but I think that's a better approach than what was there anyway. Branch ------ master Details ------- http://git.postgresql.org/pg/commitdiff/f65e8270587f3e9b8224e20f7d020ed1f816dfe1 Modified Files -------------- src/backend/utils/mmgr/mcxt.c | 71 ++++++++++++++++++++++++++++++++++++----- src/include/nodes/memnodes.h | 24 +++++++++++--- src/include/utils/memutils.h | 2 ++ 3 files changed, 85 insertions(+), 12 deletions(-)
On 27 February 2015 at 22:17, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Invent a memory context reset/delete callback mechanism. > > This allows cleanup actions to be registered to be called just before a > particular memory context's contents are flushed (either by deletion or > MemoryContextReset). The patch in itself has no use-cases for this, but > several likely reasons for wanting this exist. > > In passing, per discussion, rearrange some boolean fields in struct > MemoryContextData so as to avoid wasted padding space. For safety, > this requires making allowInCritSection's existence unconditional; > but I think that's a better approach than what was there anyway. Please can you document this in src/backend/utils/mmgr/README or other place? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, RemoteDBA, Training & Services
On Fri, 2015-02-27 at 22:17 +0000, Tom Lane wrote:
> In passing, per discussion, rearrange some boolean fields in struct
> MemoryContextData so as to avoid wasted padding space. For safety,
> this requires making allowInCritSection's existence unconditional;
> but I think that's a better approach than what was there anyway.
I notice that this uses the bytes in MemoryContextData that I was hoping
to use for the memory accounting patch (for memory-bounded HashAgg).
Leaving no space for even a 32-bit value (without AllocSetContext
growing beyond the magical 192-byte number Andres mentioned) removes
most of the options for memory accounting. The only things I can think
of are:
1. Move a few less-frequently-accessed fields out to an auxiliary
structure (Tomas proposed something similar); or
2. Walk the memory contexts, but use some kind of
estimation/extrapolation so that it doesn't need to be done for every
input tuple of HashAgg.
Thoughts?
Regards,
Jeff Davis
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 27 February 2015 at 22:17, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Invent a memory context reset/delete callback mechanism.
> Please can you document this in src/backend/utils/mmgr/README or other place?
Is anybody still reading that? OK, done.
regards, tom lane
On 28 February 2015 at 01:34, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: >> On 27 February 2015 at 22:17, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Invent a memory context reset/delete callback mechanism. > >> Please can you document this in src/backend/utils/mmgr/README or other place? > > Is anybody still reading that? OK, done. There was a recent question about memory management, so people do ask and that's still where we send 'em. Thanks. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, RemoteDBA, Training & Services