pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: hyrax vs. RelationBuildPartitionDesc
Date: Fri, 15 Mar 2019 09:32:22 +0200
Message-ID: <2efba7eb-7fab-59db-68bd-9a03e39588eb@iki.fi> (raw)
In-Reply-To: <15943.1552601288@sss.pgh.pa.us>
References: <CA+TgmoY3bRmGB6-DUnoVy5fJoreiBJ43rwMrQRCdPXuKt4Ykaw@mail.gmail.com>
	<20190313164232.GA5270@alvherre.pgsql>
	<CA+Tgmoabw8KW9rx6ThnUTR_ofJC8GwVaC+XMe7HkZvsG7J1rvA@mail.gmail.com>
	<7448.1552497345@sss.pgh.pa.us>
	<7961.1552498252@sss.pgh.pa.us>
	<CA+TgmoaZ021fRZawzU_gozwgHMo-tXJc12uf3MJoA6k=HZsLJA@mail.gmail.com>
	<10788.1552501588@sss.pgh.pa.us>
	<CA+TgmoYd3vqd26RiT4sp7Mez3oQf-AxAzdBpEeTyCNF-7OchhA@mail.gmail.com>
	<CA+TgmoY71GwY8WhQKBH+7yexyZEw6WDbFBtj2E3EDszc0LnSqQ@mail.gmail.com>
	<3969.1552581380@sss.pgh.pa.us>
	<CA+TgmoYg2NY3KTUFiuaCxDkW8iXD3o3H3wdXs6m-o-dGiYHD_Q@mail.gmail.com>
	<15943.1552601288@sss.pgh.pa.us>

On 15/03/2019 00:08, Tom Lane wrote:
> What I'm thinking, therefore, is that 2455ab488 had the right idea but
> didn't take it far enough.  We should remove the temp-context logic it
> added to RelationBuildPartitionDesc and instead put that one level up,
> in RelationBuildDesc, where the same temp context can serve all of these
> leak-prone sub-facilities.
> 
> Possibly it'd make sense to conditionally compile this so that we only
> do it in a CLOBBER_CACHE_ALWAYS build.  I'm not very sure about that,
> but arguably in a normal build the overhead of making and destroying
> a context would outweigh the cost of the leaked memory.  The main
> argument I can think of for doing it all the time is that having memory
> allocation work noticeably differently in CCA builds than normal ones
> seems like a recipe for masking normal-mode bugs from the CCA animals.

Having CLOBBER_CACHE_ALWAYS behave differently sounds horrible.

We maintain a free list of AllocSetContexts nowadays, so creating a 
short-lived context should be pretty cheap. Or if it's still too 
expensive, we could create one short-lived context as a child of 
TopMemoryContext, and reuse that on every call, resetting it at the end 
of the function.

- Heikki




view thread (71+ messages)  latest in thread

Message-ID: <2efba7eb-7fab-59db-68bd-9a03e39588eb@iki.fi>
Permalink:  ../2efba7eb-7fab-59db-68bd-9a03e39588eb@iki.fi/
Also on:    postgresql.org/message-id/2efba7eb-7fab-59db-68bd-9a03e39588eb@iki.fi

 · 

reply
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: hlinnaka@iki.fi, tgl@sss.pgh.pa.us, robertmhaas@gmail.com, alvherre@2ndquadrant.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: hyrax vs. RelationBuildPartitionDesc
  In-Reply-To: <2efba7eb-7fab-59db-68bd-9a03e39588eb@iki.fi>

* 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