Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Seems OK to me. It's worth noting though that if a module does do
> palloc+memcpy of PlannerInfo, and it's compiled against the new sources
> with the extra field, but used on an old server version, it will
> memcpy() from beyond the end of the struct. If you're seriously unlucky
> and the struct is at the end of allocated address space, that can segfault.
Yeah, and in the converse case (copied version is too small) the
reference from relation_excluded_by_constraints could segfault.
But actually, neither will happen because palloc rounds the struct
size up to a power of 2, so there will be some memory there; it
just might contain garbage.
> Unfortunately there doesn't seem to be any alignment padding in the
> struct either. You could've stuck the new field there and avoided
> changing sizeof(PlannerInfo).
Yeah, I looked for some pad space :-(
The alternative fix for 8.4 would be to not add the field but instead
grovel through app_info_list to see if the target relation is a child.
I discarded this approach because the whole point of
"constraint_exclusion = partition" is to not add overhead to simple
non-inheritance queries. However, if we think the ABI break is actually
worth worrying about then maybe that's the better fix.
I'm inclined not to worry, in part because I'm not aware of any
third-party planner hooks actually being used in production.
Does anyone know of one?
regards, tom lane