Re: [PATCH] Fix ouside scope t_ctid (ItemPointerData)
| От | Mark Dilger |
|---|---|
| Тема | Re: [PATCH] Fix ouside scope t_ctid (ItemPointerData) |
| Дата | |
| Msg-id | E90F5F90-D39B-4C18-8DAE-0D1B38E09011@enterprisedb.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] Fix ouside scope t_ctid (ItemPointerData) (Ranier Vilela <ranier.vf@gmail.com>) |
| Ответы |
Re: [PATCH] Fix ouside scope t_ctid (ItemPointerData)
|
| Список | pgsql-hackers |
> On May 14, 2020, at 11:34 AM, Ranier Vilela <ranier.vf@gmail.com> wrote:
>
> htup->t_ctid = target_tid;
> htup->t_ctid = newtid;
> Both target_tid and newtid are local variable, whe loss scope, memory is garbage.
Ok, thanks for the concrete example of what is bothering you.
In htup_details, I see that struct HeapTupleHeaderData has a field named t_ctid of type struct ItemPointerData. I also
seein heapam that target_tid is of type ItemPointerData. The
htup->t_ctid = target_tid
copies the contents of target_tid. By the time target_tid goes out of scope, the contents are already copied. I would
shareyour concern if t_ctid were of type ItemPointer (aka ItemPointerData *) and the code said
htup->t_ctid = &target_tid
but it doesn't say that, so I don't see the issue.
Also in heapam, I see that newtid is likewise of type ItemPointerData, so the same logic applies. By the time newtid
goesout of scope, its contents have already been copied into t_ctid, so there is no problem.
But maybe you know all that and are just complaining that the name "ItemPointerData" sounds like a pointer rather than
astruct? I'm still unclear whether you believe this is a bug, or whether you just don't like the naming that is used.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: