RE: [PATCH] Improve AtSubCommit_childXids

"Why is this an improvement? And what setting are we removing? You mean
that we reset nChildXids, even if it's already 0? Hard to see how that
matters."

The orginal function, ever set ChildXidsm, nChildXidsa and maxChildXids.
See at lines 1594, 1595, 1596, even if it's already 0!

The test (nChildXids > 0), possibly works, but, may confuse when do use
memcpy function soon after, and access one pointer that below, is checked by NULL.
How hard to see this?

Original file:
if (s->nChildXids > 0)
memcpy(&s->parent->childXids[s->parent->nChildXids + 1],
s->childXids, // s->childXids null pointer potential dereferencing
s->nChildXids * sizeof(TransactionId));

s->parent->nChildXids = new_nChildXids;

/* Release child's array to avoid leakage */
if (s->childXids != NULL) // Check null pointer!
pfree(s->childXids);
/* We must reset these to avoid double-free if fail later in commit */
s->childXids = NULL; // ever set to 0
s->nChildXids = 0; // ever set to 0
s->maxChildXids = 0; // ever set to 0

best regards,
Ranier Vilela
________________________________________
De: Andres Freund <andres(at)anarazel(dot)de>
Enviado: quarta-feira, 13 de novembro de 2019 17:10
Para: Ranier Vilela
Cc: PostgreSQL Hackers
Assunto: Re: [PATCH] Improve AtSubCommit_childXids

Hi,

On 2019-11-13 16:18:46 +0000, Ranier Vilela wrote:
> Surely that "s->nChildXids > 0", protects s->childXids to be NULL!
> But, when we exchange the test (s->nChildXids > 0) by (s->childXids != NULL), I believe we have the same protection, because, if "s->childXids" is not NULL, "s->nChildXids" is > 0, naturally.
>
> That way we can improve the function and avoid calling and setting unnecessarily!

Why is this an improvement? And what setting are we removing? You mean
that we reset nChildXids, even if it's already 0? Hard to see how that
matters.

> Bonus: silent compiler warning potential null pointer derenferencing.

Which compiler issues a warning here?

Greetings,

Andres Freund