Re: Time limit for a process to hold Content lock in Buffer Cache - Mailing list pgsql-hackers

From Atri Sharma
Subject Re: Time limit for a process to hold Content lock in Buffer Cache
Date
Msg-id CAOeZVieFiJahZf2yiMXx_zeFqA53SC193-uUxz-59bBszoJD+w@mail.gmail.com
Whole thread Raw
In response to Re: Time limit for a process to hold Content lock in Buffer Cache  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: Time limit for a process to hold Content lock in Buffer Cache  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, May 23, 2013 at 8:52 PM, Amit Langote <amitlangote09@gmail.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: streaming replication, "frozen snapshot backup on it" and missing relfile (postgres 9.2.3 on xfs + LVM)
Next
From: Fujii Masao
Date:
Subject: Re: pg_rewind, a tool for resynchronizing an old master after failover