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.kyot...@lab.ntt.co.jp>: > Hello, > > At Fri, 2 Oct 2015 23:13:24 +0900, Takashi Ohnishi <bwtak...@gmail.com> > wrote in <CAO38NOp66ST2K_0xGpQYe3cfsvSAgbkF4fYUg55b= > u2dwpl...@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 > >
