Subject: Re: PATCH: two slab-like memory allocators
To: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>
References: <20170227174201.yrofai7neyp6shb2@alap3.anarazel.de>
 <c7c1bb85-d1d0-05a5-4d4c-3047d6f053e7@2ndquadrant.com>
 <20170228034232.4h7ouyhxq4lbbao2@alap3.anarazel.de>
 <1240.1488254244@sss.pgh.pa.us>
 <20170228051630.3qcevakcaaa6b4ef@alap3.anarazel.de>
 <1671.1488259784@sss.pgh.pa.us>
 <20170228074420.aazv4iw6k562mnxg@alap3.anarazel.de>
 <20170228184122.extbigaer5ryrt3z@alap3.anarazel.de>
 <20170301041835.wli3viwnxr5wonfv@alap3.anarazel.de>
 <20170301042936.usv23f4iaumeyptf@alap3.anarazel.de>
 <20170301225545.eoevemua234g4fzq@alap3.anarazel.de>
Cc: Petr Jelinek <petr.jelinek@2ndquadrant.com>,
 Petr Jelinek <petr@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>,
 John Gorman <johngorman2@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Message-ID: <c5cce00e-8a10-449e-33be-67c0ea1009ef@2ndquadrant.com>
Date: Thu, 2 Mar 2017 04:47:13 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <20170301225545.eoevemua234g4fzq@alap3.anarazel.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 03/01/2017 11:55 PM, Andres Freund wrote:
> On 2017-02-28 20:29:36 -0800, Andres Freund wrote:
>> On 2017-02-28 20:18:35 -0800, Andres Freund wrote:
>>> - Andres, hoping the buildfarm turns greener
>>
>> Oh well, that didn't work. Investigating.
>
> The fix for that was fairly trivial, and the buildfarm has cooled down.
>
> The issue was that on 32bit platforms the Datum returned by some
> functions (int2int4_sum in this case) isn't actually a separately
> allocated Datum, but rather just something embedded in a larger
> struct.  That, combined with the following code:
> 	if (!peraggstate->resulttypeByVal && !*isnull &&
> 		!MemoryContextContains(CurrentMemoryContext,
> 							   DatumGetPointer(*result)))
> seems somewhat problematic to me.  MemoryContextContains() can give
> false positives when used on memory that's not a distinctly allocated
> chunk, and if so, we violate memory lifetime rules.  It's quite
> unlikely, given the required bit patterns, but nonetheless it's making
> me somewhat uncomfortable.
>

I assume you're only using that code snippet as an example of code that 
might be broken by MemoryContextContains() false positives, right?

(I don't see how the slab allocator could interfere with aggregates, as 
it's only used for reorderbuffer.c).

 >
> Do others think this isn't an issue and we can just live with it?
>

My understanding is all the places calling MemoryContextContains() 
assume they can't receive memory not allocated as a simple chunk by 
palloc(). If that's not the case, it's likely broken.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers