Re: Avoid memory leaks during base backups - Mailing list pgsql-hackers

On Thu, Sep 29, 2022 at 10:38 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> Please review the v4 patch.

I used valgrind for testing. Without patch, there's an obvious memory
leak [1], with patch no memory leak.

I used ALLOCSET_START_SMALL_SIZES instead of ALLOCSET_DEFAULT_SIZES
for backup memory context so that it can start small and grow if
required.

I'm attaching v5 patch, please review it further.

[1]
==00:00:01:36.306 145709== VALGRINDERROR-BEGIN
==00:00:01:36.306 145709== 24 bytes in 1 blocks are still reachable in
loss record 122 of 511
==00:00:01:36.306 145709==    at 0x98E501: palloc (mcxt.c:1170)
==00:00:01:36.306 145709==    by 0x9C1795: makeStringInfo (stringinfo.c:45)
==00:00:01:36.306 145709==    by 0x2DE22A: pg_backup_start (xlogfuncs.c:96)
==00:00:01:36.306 145709==    by 0x4D2DB6: ExecMakeTableFunctionResult
(execSRF.c:234)
==00:00:01:36.306 145709==    by 0x4F08DA: FunctionNext (nodeFunctionscan.c:95)
==00:00:01:36.306 145709==    by 0x4D48EA: ExecScanFetch (execScan.c:133)
==00:00:01:36.306 145709==    by 0x4D4963: ExecScan (execScan.c:182)
==00:00:01:36.306 145709==    by 0x4F0C84: ExecFunctionScan
(nodeFunctionscan.c:270)
==00:00:01:36.306 145709==    by 0x4D0255: ExecProcNodeFirst
(execProcnode.c:464)
==00:00:01:36.306 145709==    by 0x4C32D4: ExecProcNode (executor.h:259)
==00:00:01:36.306 145709==    by 0x4C619C: ExecutePlan (execMain.c:1636)
==00:00:01:36.306 145709==    by 0x4C3A0F: standard_ExecutorRun (execMain.c:363)
==00:00:01:36.306 145709==
==00:00:01:36.306 145709== VALGRINDERROR-END

==00:00:01:36.334 145709== VALGRINDERROR-BEGIN
==00:00:01:36.334 145709== 1,024 bytes in 1 blocks are still reachable
in loss record 426 of 511
==00:00:01:36.334 145709==    at 0x98E501: palloc (mcxt.c:1170)
==00:00:01:36.334 145709==    by 0x9C17CF: initStringInfo (stringinfo.c:63)
==00:00:01:36.334 145709==    by 0x9C17A5: makeStringInfo (stringinfo.c:47)
==00:00:01:36.334 145709==    by 0x2DE22A: pg_backup_start (xlogfuncs.c:96)
==00:00:01:36.334 145709==    by 0x4D2DB6: ExecMakeTableFunctionResult
(execSRF.c:234)
==00:00:01:36.334 145709==    by 0x4F08DA: FunctionNext (nodeFunctionscan.c:95)
==00:00:01:36.334 145709==    by 0x4D48EA: ExecScanFetch (execScan.c:133)
==00:00:01:36.334 145709==    by 0x4D4963: ExecScan (execScan.c:182)
==00:00:01:36.334 145709==    by 0x4F0C84: ExecFunctionScan
(nodeFunctionscan.c:270)
==00:00:01:36.334 145709==    by 0x4D0255: ExecProcNodeFirst
(execProcnode.c:464)
==00:00:01:36.334 145709==    by 0x4C32D4: ExecProcNode (executor.h:259)
==00:00:01:36.334 145709==    by 0x4C619C: ExecutePlan (execMain.c:1636)
==00:00:01:36.334 145709==
==00:00:01:36.334 145709== VALGRINDERROR-END

==00:00:01:36.335 145709== VALGRINDERROR-BEGIN
==00:00:01:36.335 145709== 1,096 bytes in 1 blocks are still reachable
in loss record 431 of 511
==00:00:01:36.335 145709==    at 0x98E766: palloc0 (mcxt.c:1201)
==00:00:01:36.335 145709==    by 0x2DE152: pg_backup_start (xlogfuncs.c:81)
==00:00:01:36.335 145709==    by 0x4D2DB6: ExecMakeTableFunctionResult
(execSRF.c:234)
==00:00:01:36.335 145709==    by 0x4F08DA: FunctionNext (nodeFunctionscan.c:95)
==00:00:01:36.335 145709==    by 0x4D48EA: ExecScanFetch (execScan.c:133)
==00:00:01:36.335 145709==    by 0x4D4963: ExecScan (execScan.c:182)
==00:00:01:36.335 145709==    by 0x4F0C84: ExecFunctionScan
(nodeFunctionscan.c:270)
==00:00:01:36.335 145709==    by 0x4D0255: ExecProcNodeFirst
(execProcnode.c:464)
==00:00:01:36.335 145709==    by 0x4C32D4: ExecProcNode (executor.h:259)
==00:00:01:36.335 145709==    by 0x4C619C: ExecutePlan (execMain.c:1636)
==00:00:01:36.335 145709==    by 0x4C3A0F: standard_ExecutorRun (execMain.c:363)
==00:00:01:36.335 145709==    by 0x4C37FA: ExecutorRun (execMain.c:307)
==00:00:01:36.335 145709==
==00:00:01:36.335 145709== VALGRINDERROR-END

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com