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
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 |