aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeHashjoin.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2000-08-22 04:06:22 +0000
committerTom Lane <tgl@sss.pgh.pa.us>2000-08-22 04:06:22 +0000
commit0147b1934f251183d3614bca011bf21205890835 (patch)
treeed7df11ba0ecbdae22095a2eeacbd204dcdca1b8 /src/backend/executor/nodeHashjoin.c
parent94e90d9a86a186c83891fe4ce3e343bcf1860053 (diff)
downloadpostgresql-0147b1934f251183d3614bca011bf21205890835.tar.gz
postgresql-0147b1934f251183d3614bca011bf21205890835.zip
Fix a many-legged critter reported by chifungfan@yahoo.com: under the
right circumstances a hash join executed as a DECLARE CURSOR/FETCH query would crash the backend. Problem as seen in current sources was that the hash tables were stored in a context that was a child of TransactionCommandContext, which got zapped at completion of the FETCH command --- but cursor cleanup executed at COMMIT expected the tables to still be valid. I haven't chased down the details as seen in 7.0.* but I'm sure it's the same general problem.
Diffstat (limited to 'src/backend/executor/nodeHashjoin.c')
0 files changed, 0 insertions, 0 deletions