Re: Pinning a buffer in TupleTableSlot is unnecessary - Mailing list pgsql-hackers

From Haribabu Kommi
Subject Re: Pinning a buffer in TupleTableSlot is unnecessary
Date
Msg-id CAJrrPGeWKi8+ayuqYjCYw9RouFmCroR8k4VL3bOg8BjhE4KZ+A@mail.gmail.com
Whole thread Raw
In response to Re: Pinning a buffer in TupleTableSlot is unnecessary  (Noah Misch <noah@leadboat.com>)
Responses Re: [HACKERS] Pinning a buffer in TupleTableSlot is unnecessary
List pgsql-hackers


On Tue, Nov 15, 2016 at 1:17 PM, Noah Misch <noah@leadboat.com> wrote:
On Mon, Nov 14, 2016 at 10:21:53AM -0800, Peter Geoghegan wrote:
> BTW, I recently noticed that the latest version of Valgrind, 3.12,
> added this new feature:
>
> * Memcheck:
>
>   - Added meta mempool support for describing a custom allocator which:
>      - Auto-frees all chunks assuming that destroying a pool destroys all
>        objects in the pool
>      - Uses itself to allocate other memory blocks
>
> It occurred to me that we might be able to make good use of this.

PostgreSQL memory contexts don't acquire blocks from other contexts; they all
draw from malloc() directly.  Therefore, I don't see this feature giving us
something that the older Memcheck MEMPOOL support does not give us.


Moved to next CF with "needs review" status.
Please feel free to update the status if the current status doesn't reflect the status
of the patch.
 
Regards,
Hari Babu
Fujitsu Australia

pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: Re: New SQL counter statistics view (pg_stat_sql)
Next
From: Haribabu Kommi
Date:
Subject: Re: Proposal for changes to recovery.conf API