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

  1. Fix memory leak in pgoutput for the WAL sender