Hi, I was trying to fix an independent problem reported by skink (caused by me) and valgrind greeted me with the following complaint during a crash-restart:
==350002== 11 bytes in 1 blocks are definitely lost in loss record 19 of 121 ==350002== at 0xFD8995: MemoryContextAlloc (mcxt.c:1250) ==350002== by 0xFD9C38: MemoryContextStrdup (mcxt.c:1751) ==350002== by 0xFD9C7F: pstrdup (mcxt.c:1761) ==350002== by 0xA184BF: dbase_redo (dbcommands.c:3375) ==350002== by 0x97BD72: ApplyWalRecord (xlogrecovery.c:2002) ==350002== by 0x97B879: PerformWalRecovery (xlogrecovery.c:1832) ==350002== by 0x96B377: StartupXLOG (xlog.c:5894) ==350002== by 0xCBD29F: StartupProcessMain (startup.c:258) ==350002== by 0xCB4B63: postmaster_child_launch (launch_backend.c:268) ==350002== by 0xCBC369: StartChildProcess (postmaster.c:3983) ==350002== by 0xCB86BA: PostmasterMain (postmaster.c:1396) ==350002== by 0xB84BF5: main (main.c:231) And I think it is right. XLOG_DBASE_CREATE_FILE_COPY is careful to pfree(parent_path), but XLOG_DBASE_CREATE_WAL_LOG isn't. This isn't a particularly bad leak, given the amounts of data involved and the cost of the underlying operation, yet it still seems like somethin we ought to fix. Greetings, Andres Freund
