Re: Connection string parameter 'replication' in documentation - Mailing list pgsql-hackers

From Takashi Ohnishi
Subject Re: Connection string parameter 'replication' in documentation
Date
Msg-id CAO38NOqmvMzVCv3EYP9=0=wWFGLE1X7AAhN7zKkLTn4JmuCAzQ@mail.gmail.com
Whole thread Raw
In response to Re: Connection string parameter 'replication' in documentation  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
Thanks for your answer:)

>This is introduced by the commit 5a991ef, which allows logical
>decoding via walsender interface. The paramter replication has
>been there far from the commit intentionary as an 'undocumented
>paramter'. This is, I suppose, because it is treated as a part of
>the replication ptorocol, not a matter of ordinary clients at
>all.

Ah, this is intentional!

>Since it has no meaning out of the context of replication agents,
>it seems reasonable that the parameter is not documented in the
>section.

I see.
But, if this parameter is for logical decoding,  I think it is better that "46.3. Streaming Replication Protocol Interface" tells about this.  


>Instead, the comment for libpqrcv_connect@libpqwalreceiver.c has
>become outedated by the commit.
>
>> * We use the expand_dbname parameter to process the connection string (or
>> * URI), and pass some extra options. The deliberately undocumented
>> * parameter "replication=true" makes it a replication connection. The
>
>This should be synced with the document.

Agreed.

--
Takashi Ohnishi

2015-10-05 19:07 GMT+09:00 Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>:
Hello,

At Fri, 2 Oct 2015 23:13:24 +0900, Takashi Ohnishi <bwtakacy@gmail.com> wrote in <CAO38NOp66ST2K_0xGpQYe3cfsvSAgbkF4fYUg55b=U2dwPLQHw@mail.gmail.com>
> I found that it can be set like 'replication = true' in connection
> parameter as documentation says in  "50.3. Streaming Replication Protocol",
> but this parameter is not denoted in "31.1.2. Parameter Key Words".

This is introduced by the commit 5a991ef, which allows logical
decoding via walsender interface. The paramter replication has
been there far from the commit intentionary as an 'undocumented
paramter'. This is, I suppose, because it is treated as a part of
the replication ptorocol, not a matter of ordinary clients at
all.

> How about adding notation about this paramter in 31.1.2.?
> Attached is a patch for that.

Since it has no meaning out of the context of replication agents,
it seems reasonable that the parameter is not documented in the
section.


Instead, the comment for libpqrcv_connect@libpqwalreceiver.c has
become outedated by the commit.

> * We use the expand_dbname parameter to process the connection string (or
> * URI), and pass some extra options. The deliberately undocumented
> * parameter "replication=true" makes it a replication connection. The

This should be synced with the document.

Thoughts?

===============
diff --git a/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c b/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
index b7bbcf6..e58c35a 100644
--- a/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
+++ b/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
@@ -94,10 +94,11 @@ libpqrcv_connect(char *conninfo)

        /*
         * We use the expand_dbname parameter to process the connection string (or
-        * URI), and pass some extra options. The deliberately undocumented
-        * parameter "replication=true" makes it a replication connection. The
-        * database name is ignored by the server in replication mode, but specify
-        * "replication" for .pgpass lookup.
+        * URI), and pass some extra options. The paramter "replication"
+        * deliberately documented out of the section for the ordiary client
+        * protocol, having "true" makes it a physical replication connection. The
+        * database name is ignored by the server in physical replication mode,
+        * but specify "replication" for .pgpass lookup.
         */
        keys[0] = "dbname";
        vals[0] = conninfo;
==========

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Freeze avoidance of very large table.
Next
From: Stephen Frost
Date:
Subject: Re: ON CONFLICT issues around whole row vars,