Aleksey Demakov <> writes:
> On Sat, Jun 18, 2016 at 12:45 AM, Tom Lane <> 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 (
To make changes to your subscription:

Reply via email to