Re: [PATCH] Fix ouside scope t_ctid (ItemPointerData) - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: [PATCH] Fix ouside scope t_ctid (ItemPointerData)
Date
Msg-id E90F5F90-D39B-4C18-8DAE-0D1B38E09011@enterprisedb.com
Whole thread Raw
In response to Re: [PATCH] Fix ouside scope t_ctid (ItemPointerData)  (Ranier Vilela <ranier.vf@gmail.com>)
Responses Re: [PATCH] Fix ouside scope t_ctid (ItemPointerData)
List 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 by date:

Previous
From: Jeremy Schneider
Date:
Subject: Re: SEQUENCE values (duplicated) in some corner cases when crash happens
Next
From: Alvaro Herrera
Date:
Subject: Re: SEQUENCE values (duplicated) in some corner cases when crashhappens