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
