On Sat, Jun 18, 2016 at 3:43 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > DSM already exists, and for many purposes its lack of a > within-a-shmem-segment dynamic allocator is irrelevant; the same purpose > is served (with more speed, more reliability, and less code) by releasing > the whole DSM segment when no longer needed. The DSM segment effectively > acts like a memory context, saving code from having to account precisely > for every single allocation it makes. > > I grant that having a dynamic allocator added to DSM will support even > more use-cases. What I'm not convinced of is that we need a dynamic > allocator within the fixed-size shmem segment. Robert already listed some > reasons why that's rather dubious, but I'll add one more: any leak becomes > a really serious bug, because the only way to recover the space is to > restart the whole database instance. >
Okay, if you say that DSM segments work the best for accumulating transient data that may be freed together when it becomes unnecessary at once, then I agree with that. My code is for long-living data that could be allocated and freed chunk by chunk. As if an extension wants to store more data and in more complicated fashion than fits to an ordinary dynahash with the HASH_SHARED_MEM flag. Regards, Aleksey -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
