Re: Is there a memory leak in commit 8561e48?

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, "jian(dot)long(at)i-soft(dot)com(dot)cn" <jian(dot)long(at)i-soft(dot)com(dot)cn>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Is there a memory leak in commit 8561e48?
Date: 2018-05-03 12:45:13
Message-ID: c6bba7e1-b9e7-f7e4-572e-2a0ba3534653@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5/2/18 20:11, Michael Paquier wrote:
> On Wed, May 02, 2018 at 07:03:21PM -0400, Tom Lane wrote:
>> It's only ~100 bytes per stack level. I think under normal loads
>> nobody would notice. If you're worried about cross-transaction
>> memory consumption, our various caches tend to be a lot worse.
>
> Perhaps, that's one reason why people drop connections from time to time
> to the server even with a custom pooler. I am wondering if we are going
> to have complains about "performance regressions" found after upgrading
> to Postgres 11 for deployments which rely on complicated PL call stacks,
> or complains about the OOM killer though. Getting to review large
> procedures stacks can be a pain for application developers.

I went with the patch I had posted, since I needed to move ahead with
something. If it turns out to be a problem, we can easily switch it around.

As Tom mentioned, in order to grow the SPI stack to where it has a
significant size, you might also overrun the OS stack and other things.
On the other hand, the current/new arrangement is a win for normal SPI
use, since you don't need to rebuild the stack on every call.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2018-05-03 12:55:01 Re: Anyone keep mirrors of old packages from apt.postgresql.org?
Previous Message Vladimir Svedov 2018-05-03 11:21:45 ParseDateTime in src/backend/utils/adt/datetime.c