Re: Time limit for a process to hold Content lock in Buffer Cache

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

In response to

Responses

Browse pgsql-hackers by date

  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