Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eIJPj-0003ER-QJ for pgsql-committers@arkaria.postgresql.org; Fri, 24 Nov 2017 19:13:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eIJPj-0004rj-2h for pgsql-committers@arkaria.postgresql.org; Fri, 24 Nov 2017 19:13:27 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eIJPi-0004rZ-JL for pgsql-committers@lists.postgresql.org; Fri, 24 Nov 2017 19:13:26 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eIJPa-0007a1-Ra for pgsql-committers@postgresql.org; Fri, 24 Nov 2017 19:13:24 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id vAOJDCGd018579; Fri, 24 Nov 2017 14:13:12 -0500 From: Tom Lane To: Tomas Vondra cc: Andres Freund , Simon Riggs , pgsql-committers , Andrew Dunstan Subject: Re: pgsql: Generational memory allocator In-reply-to: <31255.1511497154@sss.pgh.pa.us> References: <20171123001649.y2nf7422iay6cw3v@alap3.anarazel.de> <20171123193936.fncfnar5wkpx56mw@alap3.anarazel.de> <21043.1511467602@sss.pgh.pa.us> <20171123214636.unwkrkunr7m2bkii@alap3.anarazel.de> <13547.1511474676@sss.pgh.pa.us> <31255.1511497154@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Thu, 23 Nov 2017 23:19:14 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18577.1511550792.1@sss.pgh.pa.us> Date: Fri, 24 Nov 2017 14:13:12 -0500 Message-ID: <18578.1511550792@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I wrote: > Tomas Vondra 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