Re: Nicer error when connecting to standby with hot_standby=off

On 2021/03/23 3:25, James Coleman wrote:
> On Mon, Mar 22, 2021 at 1:49 PM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
>>
>>
>>
>> On 2021/03/19 23:35, James Coleman wrote:
>>> Here's an updated patch; I think I've gotten what Alvaro suggested.
>>
>> Thanks for updating the patch! But I was thinking that our consensus is
>> something like the attached patch. Could you check this patch?
>
> As far as I can tell (I might be missing something) your v5 patch does
> the same thing, albeit with different code organization. It did catch
> though that I'd neglected to add the DETAIL line as separate from the
> errmsg line.
>
> Is the attached (in the style of my v4, since I'm not following why we
> need to move the standby determination logic into a new
> CAC_NOCONSISTENT block) what you're thinking? Or is there something
> else I'm missing?

I just did that to avoid adding more CAC_state. But basically it's
ok to check hot standby at either canAcceptConnections() or
ProcessStartupPacket().

case CAC_STARTUP:
ereport(FATAL,
(errcode(ERRCODE_CANNOT_CONNECT_NOW),
- errmsg("the database system is starting up")));
+ errmsg("the database system is not accepting connections"),
+ errdetail("Consistent recovery state has not been yet reached.")));

Do you want to report this message even in crash recovery? Since crash
recovery is basically not so much related to "consistent recovery state",
at least for me the original message seems more suitable for crash recovery.

Also if we adopt this message, the server with hot_standby=off reports
"Consistent recovery state has not been yet reached." in PM_STARTUP,
but stops reporting this message at PM_RECOVERY even if the consistent
recovery state has not been reached yet. Instead, it reports "Hot standby
mode is disabled." at PM_RECOVERY. Isn't this transition of message confusing?

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION