Another error reported by valgrind on the postmaster (& children) is
the following:
==30568== Source and destination overlap in memcpy(0xBFFFEA30, 0xBFFFEA30, 24)
==30568== at 0x40024224: memcpy (mac_replace_strmem.c:93)
==30568== by 0x82081F3: set_var_from_var (numeric.c:2732)
==30568== by 0x820BDF7: power_var_int (numeric.c:4572)
==30568== by 0x820A74E: exp_var (numeric.c:4180)
==30568== by 0x820BBF4: power_var (numeric.c:4514)
==30568== by 0x8205AA0: numeric_power (numeric.c:1580)
==30568== by 0x8141814: ExecMakeFunctionResult (execQual.c:907)
==30568== by 0x8141FD5: ExecEvalFunc (execQual.c:1214)
==30568== by 0x8143E61: ExecEvalExpr (execQual.c:2253)
==30568== by 0x8141323: ExecEvalFuncArgs (execQual.c:678)
==30568== by 0x81414A0: ExecMakeFunctionResult (execQual.c:736)
==30568== by 0x8141FD5: ExecEvalFunc (execQual.c:1214)
[ triggered by one of the queries in the numeric regression test ]
I don't know of a memcpy() implementation that would actually bail out
if called with two equal pointers, but perhaps there is one in
existence somewhere. The attached patch (not yet applied) avoids this
case by returning early from set_var_from_var() if asked to assign a
numeric to itself. That also means we can skip a few memcpy()s and a
palloc(). The other way to fix this would be to just use memmove()
instead of memcpy() here: anyone have a preference?
Unless anyone objects, I'll apply this patch tonight.
-Neil