> Right, the actual signal handler will only kill the query immediately
> if the backend is in a safe state (eg, while it's waiting for a
> heavyweight lock). Otherwise it just sets a flag that's checked by
> CHECK_FOR_INTERRUPTS. See StatementCancelHandler in postgres.c.
Roger that, I will defi
Atri Sharma writes:
> Right.I believe this is part of the standard way in which we handle
> interrupts,right? Making sure that we cancel a query when the backend
> is in a state to do so,not when the interrupt actually comes in,right?
Right, the actual signal handler will only kill the query imme
On Thu, May 23, 2013 at 10:43 AM, Atri Sharma wrote:
>>
>> A little bit --- the timeout won't actually kill the query until the
>> next time control reaches a CHECK_FOR_INTERRUPTS macro that's not inside
>> a critical section. We've had issues in the past with particular code
>> paths that failed
>
> A little bit --- the timeout won't actually kill the query until the
> next time control reaches a CHECK_FOR_INTERRUPTS macro that's not inside
> a critical section. We've had issues in the past with particular code
> paths that failed to include such a check in a long-running loop, and
> ther
Atri Sharma writes:
> 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)?
A little bit --- the timeout won't actually kill the query until the
next time control reaches a CHECK_FOR_INTERRUPTS macro that's not in
On Thu, May 23, 2013 at 8:52 PM, Amit Langote 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
> No, you're not following. These would be table-level heavyweight locks,
> and there already are timeout mechanisms that work at that level.
>
Oh,right.Sorry,I missed that. I will go and research heavyweight locks now.
Thanks a ton!
Regards,
Atri
--
Regards,
Atri
l'apprenant
--
Sent via
>
> 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 versio
Atri Sharma writes:
>> 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).
> This is what I have been worried about. The locks(exclusive locks or
> content locks in buffers) can be held
> 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).
This is what I have been worried about. The locks(exclusive locks or
content locks in buffers) can be held and stalled. Cant we do any
Atri Sharma 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
On Thu, May 23, 2013 at 8:18 PM, Tom Lane wrote:
> Atri Sharma writes:
>> I was musing over a possible condition where a rogue client gets the
>> backend to process queries which take a *lot* of time(note, this is
>> only in my head atm.I may be completely wrong here).
>
>> Wouldnt something on t
Atri Sharma writes:
> I was musing over a possible condition where a rogue client gets the
> backend to process queries which take a *lot* of time(note, this is
> only in my head atm.I may be completely wrong here).
> Wouldnt something on the lines of a timeout help here?
You can already set sta
On Thu, May 23, 2013 at 8:01 PM, Tom Lane wrote:
> Atri Sharma writes:
>> On a different note, shouldn't we have a time out for a content lock
>> in buffer cache?
>
> No; the overhead of setting up and canceling such a timeout would
> greatly outweigh any possible benefit.
>
> Generally speaking,
Atri Sharma writes:
> On a different note, shouldn't we have a time out for a content lock
> in buffer cache?
No; the overhead of setting up and canceling such a timeout would
greatly outweigh any possible benefit.
Generally speaking, LWLocks are not meant to be used in situations where
the lock
Sent from my iPad
On 23-May-2013, at 16:27, Amit Kapila wrote:
> On Thursday, May 23, 2013 3:35 PM Atri Sharma wrote:
>> Hi all,
>>
>> I was searching for an existing mechanism which ensures that a crashed
>> process releases a content lock held on a page in buffer cache. Also,
>> a similar m
On Thursday, May 23, 2013 3:35 PM Atri Sharma wrote:
> Hi all,
>
> I was searching for an existing mechanism which ensures that a crashed
> process releases a content lock held on a page in buffer cache. Also,
> a similar mechanism for refcount of the page.
>
> I seem to have missed it. Do we hav
17 matches
Mail list logo
