| From: | by Yang <mobile(dot)yang(at)outlook(dot)com> |
|---|---|
| To: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com> |
| Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: memory leak in pgoutput |
| Date: | 2024-11-18 07:00:57 |
| Message-ID: | DM3PR84MB3442C5736F1207066CFBCC88E3272@DM3PR84MB3442.NAMPRD84.PROD.OUTLOOK.COM |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Raghu Dev Ramaiah | 2024-11-18 07:03:30 | A way to build PSQL 17.1 source on AIX platform |
| Previous Message | Nisha Moond | 2024-11-18 06:54:36 | Re: DOCS - pg_replication_slot . Fix the 'inactive_since' description |