From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Cc: Petr Jelinek <petr@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: John Gorman <johngorman2@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: PATCH: two slab-like memory allocators
Date: Thu, 2 Mar 2017 04:47:13 +0100
Message-ID: <c5cce00e-8a10-449e-33be-67c0ea1009ef@2ndquadrant.com> (raw)
In-Reply-To: <20170301225545.eoevemua234g4fzq@alap3.anarazel.de>
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tomas.vondra@2ndquadrant.com, andres@anarazel.de, tgl@sss.pgh.pa.us, petr.jelinek@2ndquadrant.com, petr@2ndquadrant.com, robertmhaas@gmail.com, johngorman2@gmail.com
Subject: Re: PATCH: two slab-like memory allocators
In-Reply-To: <c5cce00e-8a10-449e-33be-67c0ea1009ef@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox