|From:||Sergei Kornilov <sk(at)zsrv(dot)org>|
|To:||Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>|
|Cc:||"andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "michael(at)paquier(dot)xyz" <michael(at)paquier(dot)xyz>, "david(at)pgmasters(dot)net" <david(at)pgmasters(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: allow online change primary_conninfo|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
> 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 objections from 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.
|Next Message||Fujii Masao||2019-10-31 10:38:35||The command tag of "ALTER MATERIALIZED VIEW RENAME COLUMN"|
|Previous Message||Etsuro Fujita||2019-10-31 09:49:26||Re: [HACKERS] advanced partition matching algorithm for partition-wise join|