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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, 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-29 07:24:11
Message-ID: 20200129072411.GH145179@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 28, 2020 at 04:11:47PM -0500, Robert Haas wrote:
> On Tue, Jan 28, 2020 at 4:06 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>> 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.
>
> Well, yeah. I mean, I'm not saying it's a good idea in this instance
> to FATAL here. I'm just saying that I don't think there is a general
> rule that code which does FATAL in the postmaster is automatically
> wrong, which is what I took Michael to be suggesting.

Re-reading the thread, I can see your point that my previous email may
read like a rule applying to the postmaster, so sorry for the
confusion.

Anyway, I was referring to the point mentioned in three places of
pgwin32_ReserveSharedMemoryRegion() to not use FATAL for this
routine. The issue with the order of DLL loading is hard to miss..
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2020-01-29 07:25:08 Re: Add %x to PROMPT1 and PROMPT2
Previous Message Rafia Sabih 2020-01-29 06:55:25 Re: adding partitioned tables to publications