Re: Patch: New GUC prepared_statement_limit to limit memory used byprepared statements - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Patch: New GUC prepared_statement_limit to limit memory used byprepared statements
Date
Msg-id 20190903162550.GA15680@alvherre.pgsql
Whole thread Raw
In response to Re: Patch: New GUC prepared_statement_limit to limit memory used byprepared statements  (Daniel Migowski <dmigowski@ikoffice.de>)
Responses Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements
List pgsql-hackers
On 2019-Aug-18, Daniel Migowski wrote:

> >  - Is this a WIP patch or the final patch? Because I can see TODO
> > and non-standard comments in the patch.
> 
> Definitely work in progress! The current implementation seems to work for
> me, but might be improved, but I wanted some input from the mailing list
> before I optimize things.
> 
> The most important question is, if such a feature would find some love here.
> Personally it is essential for me because a single prepared statement uses
> up to 45MB in my application and there were cases where ORM-generated
> prepared statememts would crash my server after some time.
> 
> Then I would like to know if the current implementation would at least not
> crash (even it might by slow a bit) or if I have to take more care for
> locking in some places.

On this patch, beyond the fact that it's causing a crash in the
regression tests as evidenced by the CFbot, we seem to be waiting on the
input of the larger community on whether it's a desired feature or not.
We have Kyotaro's vote for it, but it would be good to get more.

I'm switching it as Needs Review, so that others chime in.

In the meantime, please do fix the code style: brace location and
whitespacing are not per style, as well as usage of //-comments.
Also please research and fix the crash.

Thanks

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Rearranging ALTER TABLE to avoid multi-operations bugs
Next
From: Alvaro Herrera
Date:
Subject: Re: accounting for memory used for BufFile during hash joins