Aleksey Demakov <adema...@gmail.com> writes:
> On Sat, Jun 18, 2016 at 12:45 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> You're right, but that doesn't mean that the community is going to take
>> much interest in an unportable replacement for code that already exists.
> Excuse me, what code already exists? As far as I understand, we
> compare the approach taken in my code against Robert's code that
> is not yet available to the community.
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.
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
