Insert CHECK_FOR_INTERRUPTS() calls into btree and hash index scans at the
commit1198ec5ad9d9222ee42bba50dc32c4b204604fe4
authortgl <tgl>
Tue, 5 May 2009 19:36:32 +0000 (5 19:36 +0000)
committertgl <tgl>
Tue, 5 May 2009 19:36:32 +0000 (5 19:36 +0000)
treedbb297d45d7362c463a8ecc4bcbdad200e9c0708
parent3ddf9a2bac10a3e5316b3e17f32dca64325f7cf8
Insert CHECK_FOR_INTERRUPTS() calls into btree and hash index scans at the
points where we step right or left to the next page.  This should ensure
reasonable response time to a query cancel request during an unsuccessful
index scan, as seen in recent gripe from Marc Cousin.  It's a bit trickier
than it might seem at first glance, because CHECK_FOR_INTERRUPTS() is a no-op
if executed while holding a buffer lock.  So we have to do it just at the
point where we've dropped one page lock and not yet acquired the next.

Remove CHECK_FOR_INTERRUPTS calls at the top level of btgetbitmap and
hashgetbitmap, since they're pointless given the added checks.

I think that GIST is okay already --- at least, there's a CHECK_FOR_INTERRUPTS
at a plausible-looking place in gistnext().  I don't claim to know GIN well
enough to try to poke it for this, if indeed it has a problem at all.

This is a pre-existing issue, but in view of the lack of prior complaints
I'm not going to risk back-patching.
src/backend/access/hash/hash.c
src/backend/access/hash/hashsearch.c
src/backend/access/nbtree/nbtree.c
src/backend/access/nbtree/nbtsearch.c