Re: CHECK_FOR_INTERRUPTS in spgdoinsert() isn't helpful

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: CHECK_FOR_INTERRUPTS in spgdoinsert() isn't helpful
Date: 2014-05-29 20:34:00
Message-ID: 538799B8.70708@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Claudio Freire 2014-05-29 20:34:50 Re: Extended Prefetching using Asynchronous IO - proposal and patch
Previous Message Robert Haas 2014-05-29 20:31:22 Re: Re: Logical slots not mentioned in CREATE_REPLICATION_SLOT for replication protocol docs