memory leak in dbase_redo()

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>
Date: 2025-10-09T12:08:05Z
Lists: pgsql-hackers
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



Commits

  1. dbase_redo: Fix Valgrind-reported memory leak

  2. Fix replay of create database records on standby