]> granicus.if.org Git - postgresql/commit
Ensure mark_dummy_rel doesn't create dangling pointers in RelOptInfos.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 13 Apr 2011 22:56:40 +0000 (18:56 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 13 Apr 2011 22:56:40 +0000 (18:56 -0400)
commiteca75a12a27d28b972fc269c1c8813cd8eb15441
tree083cfe9571f5d7d148fbc231dc15d0a73e7dc1c4
parent170aeb54074ae2e21b22b79d1dd5c665700f7025
Ensure mark_dummy_rel doesn't create dangling pointers in RelOptInfos.

When we are doing GEQO join planning, the current memory context is a
short-lived context that will be reset at the end of geqo_eval().  However,
the RelOptInfos for base relations are set up before that and then re-used
across many GEQO cycles.  Hence, any code that modifies a baserel during
join planning has to be careful not to put pointers to the short-lived
context into the baserel struct.  mark_dummy_rel got this wrong, leading to
easy-to-reproduce-once-you-know-how crashes in 8.4, as reported off-list by
Leo Carson of SDSC.  Some improvements made in 9.0 make it difficult to
demonstrate the crash in 9.0 or HEAD; but there's no doubt that there's
still a risk factor here, so patch all branches that have the function.
(Note: 8.3 has a similar function, but it's only applied to joinrels and
thus is not a hazard.)
src/backend/optimizer/path/joinrels.c