Avoid memcpy() with same source and destination during relmapper init.
authorTom Lane <[email protected]>
Fri, 18 Dec 2020 20:46:44 +0000 (15:46 -0500)
committerTom Lane <[email protected]>
Fri, 18 Dec 2020 20:46:44 +0000 (15:46 -0500)
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

index 6d4e179377d1beea44dc8dadcf8ca1c85d14325f..b761a9770087242f2356c452b0e2e71f0881c754 100644 (file)
@@ -839,8 +839,15 @@ write_relmap_file(bool shared, RelMapFile *newmap,
        }
    }
 
-   /* Success, update permanent copy */
-   memcpy(realmap, newmap, sizeof(RelMapFile));
+   /*
+    * Success, update permanent copy.  During bootstrap, we might be working
+    * on the permanent copy itself, in which case skip the memcpy() to avoid
+    * invoking nominally-undefined behavior.
+    */
+   if (realmap != newmap)
+       memcpy(realmap, newmap, sizeof(RelMapFile));
+   else
+       Assert(!send_sinval);   /* must be bootstrapping */
 
    /* Critical section done */
    if (write_wal)