... 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
