Re: allow online change primary_conninfo - Mailing list pgsql-hackers

From Sergei Kornilov
Subject Re: allow online change primary_conninfo
Date
Msg-id 5582691572516156@sas1-ffdbcd5f1d77.qloud-c.yandex.net
Whole thread Raw
In response to Re: allow online change primary_conninfo  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: allow online change primary_conninfo
List pgsql-hackers
Hello

> So, I'd like to propose to move the stuff to the second switch().
> (See the attached incomplete patch.) This is rather similar to
> Sergei's previous proposal, but the structure of the state
> machine is kept.

Very similar to my v4 proposal (also move RequestXLogStreaming call), but closer to currentSource reading. No
objectionsfrom me, attached patch is changed this way.
 
I renamed start_wal_receiver to startWalReceiver - this style looks more consistent to near code.

> +                    /*
> +                     * Else, check if WAL receiver is still active.
> +                     */
> +                    else if (!WalRcvStreaming())

I think we still need wait WalRcvStreaming after RequestXLogStreaming call. So I remove else branch and leave separate
condition.

> In ProcessStartupSigHup, conninfo and slotname don't need to be
> retained until the end of the function.

Agreed, I move pfree

> The log message in the function seems to be too detailed. On the
> other hand, if we changed primary_conninfo to '' (stop) or vise
> versa (start), the message (restart) looks strange.

I have no strong opinion here. These messages was changed many times during this thread lifetime, can be changed
anytime.I think this is not issue since we have no consensus about overall design.
 
Write detailed messages was proposed here: https://www.postgresql.org/message-id/20190216151025.GJ2240%40paquier.xyz

> or vise versa (start)

I explicitly check currentSource and WalRcvRunning, so we have no such messages if user had no walreceiver before.

regards, Sergei
Attachment

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: [HACKERS] advanced partition matching algorithm forpartition-wise join
Next
From: Fujii Masao
Date:
Subject: The command tag of "ALTER MATERIALIZED VIEW RENAME COLUMN"