... or on the other hand, maybe these animals are just showing more sensitivity than others to an actual code bug. skink is showing valgrind failures in this very area, on both HEAD and v13:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2020-07-08%2021%3A13%3A02 ==3166208== VALGRINDERROR-BEGIN ==3166208== Conditional jump or move depends on uninitialised value(s) ==3166208== at 0x28618D: KeepLogSeg (xlog.c:9627) ==3166208== by 0x296AC5: GetWALAvailability (xlog.c:9533) ==3166208== by 0x4FFECB: pg_get_replication_slots (slotfuncs.c:356) ==3166208== by 0x3C762F: ExecMakeTableFunctionResult (execSRF.c:234) ==3166208== by 0x3D9A9A: FunctionNext (nodeFunctionscan.c:95) ==3166208== by 0x3C81D6: ExecScanFetch (execScan.c:133) ==3166208== by 0x3C81D6: ExecScan (execScan.c:199) ==3166208== by 0x3D99A9: ExecFunctionScan (nodeFunctionscan.c:270) ==3166208== by 0x3C5072: ExecProcNodeFirst (execProcnode.c:450) ==3166208== by 0x3BD35E: ExecProcNode (executor.h:245) ==3166208== by 0x3BD35E: ExecutePlan (execMain.c:1646) ==3166208== by 0x3BE039: standard_ExecutorRun (execMain.c:364) ==3166208== by 0x3BE102: ExecutorRun (execMain.c:308) ==3166208== by 0x559669: PortalRunSelect (pquery.c:912) ==3166208== Uninitialised value was created by a stack allocation ==3166208== at 0x296A84: GetWALAvailability (xlog.c:9523) ==3166208== ==3166208== VALGRINDERROR-END and even the most cursory look at the code confirms that there's a real bug here. KeepLogSeg expects *logSegNo to be defined on entry, but GetWALAvailability hasn't bothered to initialize oldestSlotSeg. It is not clear to me which one is in the wrong; the comment for KeepLogSeg isn't particularly clear on this. regards, tom lane
