Re: pgsql: Get rid of copy_partition_key

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: pgsql: Get rid of copy_partition_key
Дата
Msg-id CA+TgmoYbpuUUUp2GhYNwWm0qkah39spiU7uOiNXLz20ASfKYoA@mail.gmail.com
обсуждение исходный текст
Ответы Re: pgsql: Get rid of copy_partition_key  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
On Thu, Dec 21, 2017 at 12:43 PM, Alvaro Herrera
<alvherre@alvh.no-ip.org> wrote:
> Get rid of copy_partition_key
>
> That function currently exists to avoid leaking memory in
> CacheMemoryContext in case of trouble while the partition key is being
> built, but there's a better way: allocate everything in a memcxt that
> goes away if the current (sub)transaction fails, and once the partition
> key is built and no further errors can occur, make the memcxt permanent
> by making it a child of CacheMemoryContext.

I'm not saying this commit is wrong, but it's a weaker form of
protection than we had before.  For instance, suppose that while
building the partition key we do a bunch of random palloc's that are
only used transiently when constructing the key.  In the old coding,
those go into the temp context and get blown up immediately; only what
we copy to the new context ends up there.  In the new way, they stick
around for as long as the relcache entry does.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Raúl Marín Rodríguez
Дата:
Сообщение: Re: [HACKERS] pow support for pgbench
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Finalizing logical replication limitations as well as potentialfeatures