From: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
---|---|
To: | Amit Langote <amitlangote09(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Time limit for a process to hold Content lock in Buffer Cache |
Date: | 2013-05-23 15:28:43 |
Message-ID: | CAOeZVieFiJahZf2yiMXx_zeFqA53SC193-uUxz-59bBszoJD+w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 23, 2013 at 8:52 PM, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
>>
>> If you let an uncooperative user issue arbitrary SQL queries, he can
>> do any number of things to put server performance into the tank.
>> For instance, take out exclusive locks on all your tables and just
>> go to sleep (although I think this is limited by table permissions in
>> recent PG versions). Or start up an unconstrained join on some giant
>> tables. etc. etc. This isn't an area that people have felt deserved
>> adding a lot of overhead to control.
>
> In such a case, would statement_timeout apply? If using
> statement_timeout, would the longest a client can stall server be
> limited to statement_timeout amount of time?
>
I am not sure, but does statement_timeout depend on *what* the query
is doing internally(i.e. if it is holding lots of locks,pins etc)?
Regards,
Atri
--
Regards,
Atri
l'apprenant
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2013-05-23 15:34:21 | Re: pg_rewind, a tool for resynchronizing an old master after failover |
Previous Message | Atri Sharma | 2013-05-23 15:26:36 | Re: Time limit for a process to hold Content lock in Buffer Cache |