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

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
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:27:29
Message-ID: CAH2-WznRdBjXVM0E8ZJ3_GfR3ui+1YXNxd3HxWPOZHKXxRV7AQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

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. But that's not the case.

> Ridiculous is your lack of education.

This isn't helping you at all.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-04-23 19:28:40 Re: HEAPDEBUGALL is broken
Previous Message Robert Haas 2020-04-23 19:21:17 Re: +(pg_lsn, int8) and -(pg_lsn, int8) operators