aboutsummaryrefslogtreecommitdiff
path: root/src/backend/commands/tablecmds.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2011-04-13 18:56:40 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2011-04-13 18:56:40 -0400
commiteca75a12a27d28b972fc269c1c8813cd8eb15441 (patch)
tree083cfe9571f5d7d148fbc231dc15d0a73e7dc1c4 /src/backend/commands/tablecmds.c
parent170aeb54074ae2e21b22b79d1dd5c665700f7025 (diff)
downloadpostgresql-eca75a12a27d28b972fc269c1c8813cd8eb15441.tar.gz
postgresql-eca75a12a27d28b972fc269c1c8813cd8eb15441.zip
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.)
Diffstat (limited to 'src/backend/commands/tablecmds.c')
0 files changed, 0 insertions, 0 deletions