|From:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|To:||Daniel Migowski <dmigowski(at)ikoffice(dot)de>|
|Cc:||Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>|
|Subject:||Re: Patch: New GUC prepared_statement_limit to limit memory used by prepared statements|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
|Next Message||Alvaro Herrera||2019-09-03 16:36:33||Re: accounting for memory used for BufFile during hash joins|
|Previous Message||Tom Lane||2019-09-03 16:21:37||Re: Rearranging ALTER TABLE to avoid multi-operations bugs|