Re: A couple of cosmetic changes around shared memory code - Mailing list pgsql-hackers

From Robert Haas
Subject Re: A couple of cosmetic changes around shared memory code
Date
Msg-id CA+Tgmob7C0Aqng=Jp+1j_6=+5R-GBO2joAwcJnJHuYWp80--ow@mail.gmail.com
Whole thread Raw
In response to Re: A couple of cosmetic changes around shared memory code  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: A couple of cosmetic changes around shared memory code  (Piotr Stefaniak <postgres@piotr-stefaniak.me>)
List pgsql-hackers
On Mon, Jun 27, 2016 at 11:40 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Tue, Jun 28, 2016 at 6:49 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Sun, Jun 26, 2016 at 6:19 AM, Piotr Stefaniak
>> <postgres@piotr-stefaniak.me> wrote:
>>>> while investigating the shm_mq code and its testing module I made some
>>>> cosmetic improvements there. You can see them in the attached diff file.
>>>
>>> Revised patch attached.
>>
>> The first hunk of this corrects an outdated comment, so we should
>> certainly apply that.  I'm not seeing what the value of the other bits
>> is.
>
> - proc_exit(1);
> + proc_exit(0);
> Looking again at this thread with fresh eyes, isn't the origin of the
> confusion the fact that we do need to have a non-zero error code so as
> the worker is never restarted thanks to BGW_NEVER_RESTART? Even with
> that, it is a strange concept to leave with proc_exit(1) in the case
> where a worker left correctly..

This code predates be7558162acc5578d0b2cf0c8d4c76b6076ce352, prior to
which proc_exit(0) forced an immediate, unconditional restart.  It's
true that, given that commit, changing this code to do proc_exit(0)
instead of proc_exit(1) would be harmless.  However, people writing
background workers that might need to work with 9.3 would be best
advised to stick with proc_exit(1).  Therefore, I maintain that this
is not broken and doesn't need to be fixed.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: parallel workers and client encoding
Next
From: Andres Freund
Date:
Subject: Re: Reviewing freeze map code