Akshay, We need to think on cancelling the autocomplete in the backend after a certain timeout.
On Fri, Aug 5, 2022 at 7:08 PM Cherio <che...@gmail.com> wrote: > Thanks Akshay, that's what I meant by "switched autocomplete to manual". > > That however doesn't really address the issue. I can still bring down the > pgAdmin backend (for everyone using it) by clicking Ctrl+Space on a > complex/rogue SQL. > > On Fri, Aug 5, 2022 at 4:35 AM Akshay Joshi <akshay.jo...@enterprisedb.com> > wrote: > >> Hi Cherio >> >> You can disable the automatic autocomplete option from "File -> >> Preferences -> Query Tool -> Auto completion -> Autocomplete on key press". >> We have also fixed an issue to stop autocomplete on arrow keys #7573 >> <https://redmine.postgresql.org/issues/7573> which will be available in >> the next release, meanwhile, you can install the snapshot build >> <https://www.postgresql.org/ftp/pgadmin/pgadmin4/snapshots/>. >> >> >> >> On Wed, Aug 3, 2022 at 11:39 PM Cherio <che...@gmail.com> wrote: >> >>> I had to examine certain aspects of a query that looks like this: >>> >>> SELECT COUNT(*) >>> FROM schema.table >>> WHERE id IN ( >>> '1', >>> '2', >>> '3', >>> .... >>> '19998', >>> '19999', >>> '20000' >>> ) >>> >>> I pasted the query and autocomplete kicked in. For a minute it froze >>> entirely. Then it sort of let me do things but everything was like in slow >>> motion: the tree browser, the other SQL tabs - everything became slow as >>> molasses. I logged onto the server and the "pgAdmin4.py" was >>> keeping the CPU quite busy. It didn't recover for some time so I simply >>> restarted the server and switched autocomplete to manual. >>> >>> Not knowing the design I may not be able to make a viable suggestion but >>> maybe some sort of complexity counter (configurable or at least hard-coded >>> at first) should be considered, which would hint to the autocomplete to >>> stop trying, after it realizes the task may be too complex or takes too >>> long to complete. >>> >>> Sure, a query like the one above should probably make use of a temporary >>> table but it is beyond the point - there has to be a safeguard against an >>> overloaded autocomplete. Without such a safeguard an ugly/invalid query or >>> a user error could kill the server for all connected pgadmin clients. >>> >>>> >> >> -- >> >> <http://www.enterprisedb.com> >> >> Akshay Joshi >> >> Principal Software Architect >> >> +91 9767888246 >> >> www.enterprisedb.com >> >> <https://www.linkedin.com/company/edbpostgres> >> <https://twitter.com/edbpostgres?lang=en> >> <https://www.facebook.com/EDBpostgres> >> <https://www.instagram.com/EDBpostgres/> >> > -- Thanks, Aditya Toshniwal pgAdmin Hacker | Software Architect | *edbpostgres.com* <http://edbpostgres.com> "Don't Complain about Heat, Plant a TREE"
