| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: CHECK_FOR_INTERRUPTS in spgdoinsert() isn't helpful |
| Date: | 2014-05-29 20:41:37 |
| Message-ID: | 16812.1401396097@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> On 05/29/2014 11:25 PM, Tom Lane wrote:
>> In point of fact, we'd be happy to give up the locks and then throw
>> the error. So I was thinking about inventing some macro or out-of-line
>> function that went about like this:
>>
>> if (InterruptPending && (QueryCancelPending || ProcDiePending))
>> {
>> LWLockReleaseAll();
>> ProcessInterrupts();
>> elog(ERROR, "ProcessInterrupts failed to throw an error");
>> }
> Also checking that CritSectionCount == 0 seems like a good idea...
Yeah, and there may be a couple other details like that. Right now
I'm just thinking about not allowing LWLocks to block the cancel.
I guess something else to consider is whether InterruptHoldoffCount
could be larger than the number of held LWLocks; if so, that would
prevent this from working as desired.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2014-05-29 20:42:31 | Re: CHECK_FOR_INTERRUPTS in spgdoinsert() isn't helpful |
| Previous Message | Heikki Linnakangas | 2014-05-29 20:39:56 | Re: Extended Prefetching using Asynchronous IO - proposal and patch |