summaryrefslogtreecommitdiff
path: root/src/backend/utils/cache/ts_cache.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2012-01-04 18:31:08 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2012-01-04 18:31:08 -0500
commitc024a3b3be1c86459f9b47f81f61cb8a67ee2712 (patch)
treec408dfca4b1488198b9bad32995905f289a8cffb /src/backend/utils/cache/ts_cache.c
parent7443ab2b348d190e8784a2684a5b6ae91f7dcd4b (diff)
Make executor's SELECT INTO code save and restore original tuple receiver.
As previously coded, the QueryDesc's dest pointer was left dangling (pointing at an already-freed receiver object) after ExecutorEnd. It's a bit astonishing that it took us this long to notice, and I'm not sure that the known problem case with SQL functions is the only one. Fix it by saving and restoring the original receiver pointer, which seems the most bulletproof way of ensuring any related bugs are also covered. Per bug #6379 from Paul Ramsey. Back-patch to 8.4 where the current handling of SELECT INTO was introduced.
Diffstat (limited to 'src/backend/utils/cache/ts_cache.c')
0 files changed, 0 insertions, 0 deletions