Re: [PATCH] Windows port, fix some resources leaks - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: [PATCH] Windows port, fix some resources leaks
Date
Msg-id CAEudQApiqODoUONWU0yrfLPKeekVgO03ja77FDTt1W+LUXQrKg@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Windows port, fix some resources leaks  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Em ter., 28 de jan. de 2020 às 18:06, Alvaro Herrera <alvherre@2ndquadrant.com> escreveu:
On 2020-Jan-28, Robert Haas wrote:

> On Fri, Jan 24, 2020 at 2:13 AM Michael Paquier <michael@paquier.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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Removing pg_pltemplate and creating "trustable" extensions
Next
From: Floris Van Nee
Date:
Subject: RE: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()