Re: [PATCH] Windows port, fix some resources leaks

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Juan José Santamaría Flecha <juanjo(dot)santamaria(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Windows port, fix some resources leaks
Date: 2020-01-28 21:19:48
Message-ID: CAEudQApiqODoUONWU0yrfLPKeekVgO03ja77FDTt1W+LUXQrKg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em ter., 28 de jan. de 2020 às 18:06, Alvaro Herrera <
alvherre(at)2ndquadrant(dot)com> escreveu:

> On 2020-Jan-28, Robert Haas wrote:
>
> > On Fri, Jan 24, 2020 at 2:13 AM Michael Paquier <michael(at)paquier(dot)xyz>
> wrote:
> > > No, that's not right. I think that it is possible to loop over
> > > ShmemProtectiveRegion in some cases. And actually, your patch is dead
> > > wrong because this is some code called by the postmaster and it cannot
> > > use FATAL.
> >
> > Uh, really? I am not aware of such a rule.
>
> I don't think we have ever expressed it as such, but certainly we prefer
> postmaster to be super robust ... rather live with a some hundred bytes
> leak rather than have it die and take the whole database service down
> for what's essentially a fringe bug that has bothered no one in a decade
> and a half.
>
Maybe it didn't bother anyone, because the Windows port is much less used.
Anyway, I believe that freeing the memory before returning false, will not
bring down the service, changing the patch to LOG, instead of FATAL.
The primary error of the patch was to use FATAL.

regards,
Ranier Vilela

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Floris Van Nee 2020-01-28 21:34:34 RE: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()
Previous Message Tom Lane 2020-01-28 21:16:56 Re: Removing pg_pltemplate and creating "trustable" extensions