Re: when the startup process doesn't (logging startup delays) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: when the startup process doesn't (logging startup delays)
Date
Msg-id CA+TgmoaHOAQabALH4tfU7LUb-V3Bh0B0A4uDXZLZA2pirWj8MQ@mail.gmail.com
Whole thread Raw
In response to Re: when the startup process doesn't (logging startup delays)  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: when the startup process doesn't (logging startup delays)
List pgsql-hackers
On Sun, Nov 20, 2022 at 9:20 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
> I prefer Robert's approach as it is more robust for future changes and
> simple. I prefer to avoid this kind of piggy-backing and it doesn't
> seem to be needed in this case. XLogShutdownWalRcv() looks like a
> similar case to me and honestly I don't like it in the sense of
> robustness but it is simpler than checking walreceiver status at every
> site that refers to the flag.

I don't understand what you want changed. Can you be more specific
about what you mean by "Robert's approach"?

I don't agree with Bharath's logic for preferring an if-test to an
Assert. There are some cases where we think we've written the code
correctly but also recognize that the logic is complicated enough that
something might slip through the cracks. Then, a runtime check makes
sense, because otherwise something real bad might happen on a
production instance. But here, I don't think that's the main risk. I
think the main risk is that some future patch tries to add code that
should print startup log messages later on. That would probably be a
coding mistake, and Assert would alert the patch author about that,
whereas amending the if-test would just make the code do something
differently then the author intended.

But I don't feel super-strongly about this, which is why I mentioned
both options in my previous email. I'm not clear on whether you are
expressing an opinion on this point in particular or something more
general.

Thanks,

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Sending SIGABRT to child processes (was Re: Strange failure on mamba)
Next
From: Tom Lane
Date:
Subject: Re: Reducing power consumption on idle servers