Re: DO with a large amount of statements get stuck with high memory consumption

From: Jan Wieck <jan(at)wi3ck(dot)info>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: DO with a large amount of statements get stuck with high memory consumption
Date: 2016-07-18 14:37:06
Message-ID: CAGBW59dCR3cGEs68Cpe1F5hL+-2r8JPNTb1fDGf-M-jyKxJUUQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 18, 2016 at 10:05 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Jan Wieck <jan(at)wi3ck(dot)info> writes:
> > In the meantime, would it be appropriate to backpatch the double linking
> > of memory context children at this time? I believe it has had plenty of
> > testing in the 9.6 cycle to be sure it didn't break anything.
>
> I'm concerned about the ABI breakage risk from changing a data structure
> as fundamental as MemoryContext. Yeah, code outside utils/mmgr probably
> *shouldn't* be looking at that struct, but that doesn't mean it isn't.
> In the past we've generally only taken that sort of risk when there was
> no other way to fix a bug; and this patch isn't a bug fix. While this
> does help performance in some corner cases, I don't think it's enough of
> an across-the-board win to justify the risk of back-patching.
>

I would consider mucking with the linked lists of memory context children
inside
of 3rd party code a really bad idea, but I concede. It isn't a bug fix and
there is
that small risk that somebody did precisely that, so no backpatch.

Regards, Jan

--
Jan Wieck
Senior Postgres Architect
http://pgblog.wi3ck.info

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jason Kim 2016-07-18 14:51:11 Re: [PROPOSAL] timestamp informations to pg_stat_statements
Previous Message Tom Lane 2016-07-18 14:32:02 Re: rethinking dense_alloc (HashJoin) as a memory context