aboutsummaryrefslogtreecommitdiff
path: root/src/backend/commands/dbcommands.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2009-05-05 19:36:32 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2009-05-05 19:36:32 +0000
commit8f348112f35d9dcc28fc575f8bae458883c5700a (patch)
treea2ca46d659d8c8ab714d240a2b1cbf3f0835c034 /src/backend/commands/dbcommands.c
parent2aa5ca952f085c5a469cf6b261f39439a22b5970 (diff)
downloadpostgresql-8f348112f35d9dcc28fc575f8bae458883c5700a.tar.gz
postgresql-8f348112f35d9dcc28fc575f8bae458883c5700a.zip
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.
Diffstat (limited to 'src/backend/commands/dbcommands.c')
0 files changed, 0 insertions, 0 deletions