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
