Re: memory leak in pgoutput
by Yang <mobile.yang@outlook.com>
From: by Yang <mobile.yang@outlook.com>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2024-11-18T07:00:57Z
Lists: pgsql-hackers
> Here, after freeing the tupledesc, the ExecDropSingleTupleTableSlot will still
> access the freed tupledesc->tdrefcount which is an illegal memory access.
Yes, I overlooked that.
> I think we can do something like below instead:
>
> + TupleDesc desc = entry->old_slot->tts_tupleDescriptor;
> +
> + Assert(desc->tdrefcount == -1);
> +
> ExecDropSingleTupleTableSlot(entry->old_slot);
> + FreeTupleDesc(desc);
It seems a bit odd because "entry->old_slot->tts_tupleDescriptor" is accessed
after "entry->old_slot" has been freed. I think we can avoid this by assigning
"desc" to NULL before ExecDropSingleTupleTableSlot().
```
+ TupleDesc desc = entry->old_slot->tts_tupleDescriptor;
+
+ Assert(desc->tdrefcount == -1);
+
+ FreeTupleDesc(desc);
+ desc = NULL;
ExecDropSingleTupleTableSlot(entry->old_slot);
```
By the way, this issue is introduced in 52e4f0cd472d39d. Therefore, we may need
to backport the patch to v15.
Best Regards,
Boyu Yang
Commits
-
Fix memory leak in pgoutput for the WAL sender
- 6fc30c24cb7f 15.11 landed
- e749eaf46e9b 16.7 landed
- afe9b0d9fee1 17.3 landed
- ea792bfd93ab 18.0 landed