aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-12-18 15:46:44 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2020-12-18 15:46:44 -0500
commit722eb325b9511e9d0a8669112c636edebe2cb01b (patch)
tree77012f512df800519afc6de347468aefbe9464b5 /src/backend/executor
parentd28a14d2d4009cec91f9d0f0ceaa60f06c6e289c (diff)
downloadpostgresql-722eb325b9511e9d0a8669112c636edebe2cb01b.tar.gz
postgresql-722eb325b9511e9d0a8669112c636edebe2cb01b.zip
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 5b630501e, d3f4e8a8a, ad7b48ea0, 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
Diffstat (limited to 'src/backend/executor')
0 files changed, 0 insertions, 0 deletions