Re: [PATCH] FIx resource leaks (pg_resetwal.c)

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] FIx resource leaks (pg_resetwal.c)
Date: 2020-04-23 19:47:00
Message-ID: CAEudQApaiZO74gJhshqm6qn8QAqp3Rj9eR-tFzEmsnso3pEVKg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em qui., 23 de abr. de 2020 às 16:27, Peter Geoghegan <pg(at)bowt(dot)ie> escreveu:

> On Thu, Apr 23, 2020 at 11:41 AM Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
> wrote:
> > And if I already propose a solution even if it is not the best, it is
> much better than being silent and missing the opportunity to fix a bug.
>
> The problem with that theory is that you're not creating any value
> over simply running Coverity directly. Your patches don't seem to be
> based on any real analysis beyond what makes Coverity stop
> complaining, which is not helpful.
>
In some cases, this may be true. But in fact I already fixed some bugs with
this technique. Even you already used a patch of mine to provide a fix.
Wasn't that helpful?
1.
https://www.postgresql.org/message-id/CAEudQAqJ%3DMVqJd4MHi%3DiMLismngE4GJqdiEZa1isxF3Pem-udg%40mail.gmail.com

> For example, the nbtree.c/btvacuumpage() issue you reported yesterday
> involved a NULL pointer dereference, but if the code path in question
> ever dereferenced the NULL pointer then it would be fundamentally
> wrong in many other ways, probably leading to data corruption. The fix
> that you posted obviously completely missed the point. Even when
> Coverity identifies a serious issue, it usually needs to be carefully
> interpreted.
>
I disagree. In case of nbtree.c/btvacuumpag().
If you are validating "opaque" pointer, in three different ways to proceed
with cleaning, nothing more correct than validating the most important
first, if the pointer is really valid. And that is what the patch does.

>
> Anybody can run Coverity. Many of us do. Maybe the approach you've
> taken would have had a noticeable benefit if you were not dealing with
> a codebase that has already been subject to lots of triage of Coverity
> issues.
>
Sorry, but the plsql-bugs list, has many reports of segmentation faults,
that shouldn't exist, if everyone uses Coverity or other tools, after
writing the code.

> > Ridiculous is your lack of education.
>
> This isn't helping you at all.
>
Consideration and respect first.

regards,
Ranier Vilela

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2020-04-23 19:57:14 Re: [PATCH] FIx resource leaks (pg_resetwal.c)
Previous Message Robert Haas 2020-04-23 19:43:43 Re: [PATCH] FIx resource leaks (pg_resetwal.c)