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

From Noah Misch
Subject Re: Pinning a buffer in TupleTableSlot is unnecessary
Date
Msg-id 20161115021731.GA2269998@tornado.leadboat.com
Whole thread Raw
In response to Re: Pinning a buffer in TupleTableSlot is unnecessary  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Pinning a buffer in TupleTableSlot is unnecessary
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: "Tsunakawa, Takayuki"
Date:
Subject: Re: Remove the comment on the countereffectiveness of large shared_buffers on Windows
Next
From: "Tsunakawa, Takayuki"
Date:
Subject: Re: [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly