Re: pgsql: Generational memory allocator

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tv(at)fuzzy(dot)cz>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-committers <pgsql-committers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: pgsql: Generational memory allocator
Date: 2017-11-24 19:13:12
Message-ID: 18578.1511550792@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

I wrote:
> Tomas Vondra <tv(at)fuzzy(dot)cz> writes:
>> Thanks. Do we need to do something similar to the other memory contexts?
>> I see Slab does not do this at all (assuming it's not necessary), and
>> AllocSet does this in a different way (which seems a bit strange).

> Hm ... the coding in AllocSet is ancient and I have to say that I don't
> like it as well as what I put into generation.c.

I take that back: the current coding of padding in AllocChunkData only
dates back to 7e3aa03b. But I still don't like it, and will migrate
generation.c's version into aset.c. And maybe improve the comments.

BTW, it appears that some of the confusion in generation.c can be
accounted for by not having entirely followed the changes in 7e3aa03b.

regards, tom lane

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2017-11-24 20:50:31 pgsql: Mostly-cosmetic improvements in memory chunk header alignment co
Previous Message Tom Lane 2017-11-24 18:43:40 pgsql: Fix bug in generation.c's valgrind support.