On Mon, Sep 12, 2016 at 11:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
>> Indeed, and the query field does not have much more meaning for a WAL
>> sender. So I'd propose the attached for 9.6 and HEAD. I have thought
>> about reporting that to pgstat in StartReplication(), but as there is
>> some error handling there I'd think that WalSndLoop() is a better
>> place to call pgstat_report_activity, as per the attached.
>
> As long as it's a fixed string there's no reason to set it repeatedly,
> so this placement looks fine for now. We can reconsider when/if we
> make it variable and decide what is going to drive it.
>
> On reflection, maybe s/walsender/WAL sender/? It doesn't look like
> we really use the word "walsender" in user-facing docs.
Indeed, that may be better for clarity.
Except from the release notes, walsender is mentioned a couple of
times in the protocol docs, as *walsender mode*:
src/sgml/high-availability.sgml: a corresponding walsender process
in the primary.
src/sgml/protocol.sgml: Copy-both mode is initiated when a backend
in walsender mode
src/sgml/protocol.sgml:of <literal>true</> tells the backend to go
into walsender mode, wherein a
src/sgml/protocol.sgml:the simple query protocol can be used in walsender mode.
src/sgml/protocol.sgml:Passing <literal>database</> as the value
instructs walsender to connect to
src/sgml/protocol.sgml:The commands accepted in walsender mode are:
So that looked adapted to me at first sight. Actually, the text had
better be "WAL sender" and not "walsender" in high-availability, no?
That refers to the process, and not the backend mode.
--
Michael