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