Re: [PATCH] ecpg: fix progname memory leak

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Bruce Momjian <bruce(at)momjian(dot)us>, Michael Meskes <meskes(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] ecpg: fix progname memory leak
Date: 2020-10-09 15:48:40
Message-ID: CABUevEy84MQRvSJ=yVeBo_KXEe84mHEDFsGsoXDU1i7Mz9Sktw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 9, 2020 at 1:08 PM John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
wrote:

>
> On Fri, Oct 9, 2020 at 4:47 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
>> Now, I don't actually suggest we *remove* it, as there is valuable curated
>> content, but that we rename it to something which won't encourage
>> newcomers to
>> pick something from the list simply because it exists. The name "TODO"
>> implies
>> that the list is something which it isn't.
>
>
> +1
>

+1 as well. The way things are today, that is a terrible name, and has been
for a double-digit number of years.

The name is very much at odds with the content. To pick one baffling
> example, there's an entry under Free Space Map that dates to before the
> on-disk FSM was invented. A more accurate, if not charitable, description
> is "archive of stalled discussions". This is just a side effect of
> non-controversial todos getting finished over time. That could be helped
> with a round of aggressive culling.
>

That is one very good example indeed.

Also, it's organized by functionality, which makes sense in a way, but I
> don't find very useful in this context. Better categories might be
>
> help-wanted,
> good-first-issue (I know this is a tough one),
> feature-request,
> won't-fix (The memory leaks under discussion go here, it seems),
> code-cleanup,
> research-project,
> documentation,
> performance,
> user-experience,
> sql-standard
> etc.
>
> I suspect we will eventually want something like a full-blown issue
> tracker, although I gather that's been rejected previously. But a wiki
> page is not really suited for this.
>

Talk about "possibly controversial proposal" eh?

That said, having this in a different format would in no way fix the fact
that the information is mislabeled and obsolete. It would likely be
equally mislabeled and obsolete in an issue tracker. Just look at almost
any of the other projects out there that *do* use an issue tracker and have
been around for 20+ years.

That said, I am a believer in that we should have one, yes. But I am
equally certain that it would not help with *this* particular problem.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-10-09 16:14:17 Re: Expansion of our checks for connection-loss errors
Previous Message Ranier Vilela 2020-10-09 15:24:16 Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)