Em qua., 22 de abr. de 2020 às 21:24, Peter Geoghegan <p...@bowt.ie> escreveu:
> On Wed, Apr 22, 2020 at 3:55 PM Ranier Vilela <ranier...@gmail.com> wrote: > > per Coverity. > > Some Postgres hackers have access to a dedicated coverity > installation, and this issue has probably already been dismissed. > I will take a note. > > > 1. assign_zero: Assigning: opaque = NULL. > > 2. Condition buf < 0, taking true branch. > > 3. Condition !(((PageHeader)page)->pd_upper == 0), taking false branch. > > 4. Condition blkno != orig_blkno, taking true branch. > > 5. Condition _bt_page_recyclable(page), taking false branch. > > CID 1314742 (#2 of 2): Explicit null dereferenced (FORWARD_NULL) > > 6. var_deref_op: Dereferencing null pointer opaque. > > This is a false positive. btvacuumpage() is supposed to be a recursive > function, but in practice the only caller always uses the same block > number for both blkno and orig_blkno -- the tail recursion is actually > implemented using goto/a loop. > This means that it is impossible for these conditions described by Coverity to happen on the first call, when the var opaque is NULL. regards, Ranier Vilela
