| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
| Cc: | 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:01:01 |
| Message-ID: | 15879.1369321261@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Atri Sharma <atri(dot)jiit(at)gmail(dot)com> writes:
> BTW, what is your opinion on a rogue client's damaging capabilities?
> Theoretically, what can a client which tries to stall the backend
> target?
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Atri Sharma | 2013-05-23 15:08:37 | Re: Time limit for a process to hold Content lock in Buffer Cache |
| Previous Message | Atri Sharma | 2013-05-23 14:53:48 | Re: Time limit for a process to hold Content lock in Buffer Cache |