Re: Pinning a buffer in TupleTableSlot is unnecessary

Поиск
Список
Период
Сортировка
От Haribabu Kommi
Тема Re: Pinning a buffer in TupleTableSlot is unnecessary
Дата
Msg-id CAJrrPGeWKi8+ayuqYjCYw9RouFmCroR8k4VL3bOg8BjhE4KZ+A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Pinning a buffer in TupleTableSlot is unnecessary  (Noah Misch <noah@leadboat.com>)
Ответы Re: [HACKERS] Pinning a buffer in TupleTableSlot is unnecessary  (Michael Paquier <michael.paquier@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Haribabu Kommi
Дата:
Сообщение: Re: New SQL counter statistics view (pg_stat_sql)
Следующее
От: Haribabu Kommi
Дата:
Сообщение: Re: Proposal for changes to recovery.conf API