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

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Atri Sharma <atri(dot)jiit(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Langote <amitlangote09(at)gmail(dot)com>, 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:47:01
Message-ID: CAHyXU0z_5VwMx_5e4AZt3uT5u7p+m5+73XK2x4VjoRJUEjMoVw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 23, 2013 at 10:43 AM, Atri Sharma <atri(dot)jiit(at)gmail(dot)com> 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 to include such a check in a long-running loop, and
>> there might still be some left. But by and large, it won't take very
>> long for the query to notice the interrupt.
>
>
> 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?

yes. all non trivial parts of the code (in terms of time) must run the
interrupt check. it basically just looks a the signal flag set by the
signal handler.

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-05-23 15:49:07 Re: Time limit for a process to hold Content lock in Buffer Cache
Previous Message Atri Sharma 2013-05-23 15:43:59 Re: Time limit for a process to hold Content lock in Buffer Cache