Avoid memcpy() with same source and destination during relmapper init.
authorTom Lane
Fri, 18 Dec 2020 20:46:44 +0000 (15:46 -0500)
committerTom Lane
Fri, 18 Dec 2020 20:46:44 +0000 (15:46 -0500)
commitba04cedf1d262f3d7dfe6950b13a7ed1d80a9502
tree7c82bcde94a3cdd7a6b5485809d12136246d0e9c
parentf32c6873556f5101b2ce7436f2508b9f44ef30d6
Avoid memcpy() with same source and destination during relmapper init.

A narrow reading of the C standard says that memcpy(x,x,n) is undefined,
although it's hard to envision an implementation that would really
misbehave.  However, analysis tools such as valgrind might whine about
this; accordingly, let's band-aid relmapper.c to not do it.

See also 5b630501ed3f4e8a8aad7b48ea0, and other similar fixes.
Apparently, none of those folk tried valgrinding initdb?  This has been
like this for long enough that I'm surprised it hasn't been reported
before.

Back-patch, just in case anybody wants to use a back branch on a platform
that complains about this; we back-patched those earlier fixes too.

Discussion: https://postgr.es/m/161790.1608310142@sss.pgh.pa.us
src/backend/utils/cache/relmapper.c