Re: CHECK_FOR_INTERRUPTS in spgdoinsert() isn't helpful - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: CHECK_FOR_INTERRUPTS in spgdoinsert() isn't helpful
Date
Msg-id 538799B8.70708@vmware.com
Whole thread Raw
In response to CHECK_FOR_INTERRUPTS in spgdoinsert() isn't helpful  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: CHECK_FOR_INTERRUPTS in spgdoinsert() isn't helpful
Re: CHECK_FOR_INTERRUPTS in spgdoinsert() isn't helpful
List pgsql-hackers
On 05/29/2014 11:25 PM, Tom Lane wrote:
> One of the annoying things about the SPGiST bug Teodor pointed out is
> that once you're in the infinite loop, query cancel doesn't work to get
> you out of it.  There are a couple of CHECK_FOR_INTERRUPTS() calls in
> spgdoinsert() that are meant to get you out of exactly this sort of
> buggy-opclass situation --- but they don't help.  The reason is that
> when we reach that point we're holding one or more buffer locks, which
> means the HOLD_INTERRUPTS count is positive, so ProcessInterrupts is
> afraid to do anything.
>
> 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");
>     }
>
> where we don't expect to reach the final elog; it's just there to make
> sure we don't return control after yanking locks out from under the
> caller.

Also checking that CritSectionCount == 0 seems like a good idea...

- Heikki



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Re: Logical slots not mentioned in CREATE_REPLICATION_SLOT for replication protocol docs
Next
From: Claudio Freire
Date:
Subject: Re: Extended Prefetching using Asynchronous IO - proposal and patch