public inbox for [email protected]
help / color / mirror / Atom feedlibpq options
13+ messages / 9 participants
[nested] [flat]
* libpq options
@ 2017-11-22 13:27 [email protected]
2017-11-22 14:36 ` Re: libpq options Michael Paquier <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: [email protected] @ 2017-11-22 13:27 UTC (permalink / raw)
To: pgsql-docs
The following documentation comment has been logged on the website:
Page: https://www.postgresql.org/docs/9.6/static/libpq-connect.html
Description:
Hi everyone,
The documentation refers the libpq connection option "replication" here in
"Streaming Replication Protocol" page;
https://www.postgresql.org/docs/current/static/protocol-replication.html
However the option "replication" is not clarified (or even listed) in libpq
options page.
https://www.postgresql.org/docs/current/static/libpq-connect.html#LIBPQ-PARAMKEYWORDS
I searched the source and find that pg_conn struct has this
struct pg_conn
{
...
char *replication; /* connect as the replication standby? */
...
}
Adding something simple like above and referring back to one of replication
pages would be good I think.
thanks
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: libpq options
2017-11-22 13:27 libpq options [email protected]
@ 2017-11-22 14:36 ` Michael Paquier <[email protected]>
2017-11-25 10:05 ` Re: libpq options Michael Paquier <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: Michael Paquier @ 2017-11-22 14:36 UTC (permalink / raw)
To: [email protected]; +Cc: pgsql-docs
On Wed, Nov 22, 2017 at 10:27 PM, <[email protected]> wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/9.6/static/libpq-connect.html
> Description:
>
> The documentation refers the libpq connection option "replication" here in
> "Streaming Replication Protocol" page;
>
> https://www.postgresql.org/docs/current/static/protocol-replication.html
>
> However the option "replication" is not clarified (or even listed) in libpq
> options page.
>
> https://www.postgresql.org/docs/current/static/libpq-connect.html#LIBPQ-PARAMKEYWORDS
>
> I searched the source and find that pg_conn struct has this
>
> struct pg_conn
> {
> ...
> char *replication; /* connect as the replication standby? */
> ...
> }
>
> Adding something simple like above and referring back to one of replication
> pages would be good I think.
Yeah, it is mainly a developer option which is why I guess it is not
documented. Like you, I think it should be added as part of the
connection parameter, and mentioned it a couple of days back:
https://www.postgresql.org/message-id/CAB7nPqQAtKfG3H%2BuK11JNivtJtZYE9yVCrPuejRMjp8tUDe0nQ%40mail.g...
--
Michael
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: libpq options
2017-11-22 13:27 libpq options [email protected]
2017-11-22 14:36 ` Re: libpq options Michael Paquier <[email protected]>
@ 2017-11-25 10:05 ` Michael Paquier <[email protected]>
2017-11-28 08:00 ` Re: libpq options Şahap Aşçı <[email protected]>
2018-03-01 09:35 ` Re: libpq options Andres Freund <[email protected]>
0 siblings, 2 replies; 13+ messages in thread
From: Michael Paquier @ 2017-11-25 10:05 UTC (permalink / raw)
To: [email protected]; +Cc: pgsql-docs; Fujii Masao <[email protected]>
On Wed, Nov 22, 2017 at 11:36 PM, Michael Paquier
<[email protected]> wrote:
> Yeah, it is mainly a developer option which is why I guess it is not
> documented. Like you, I think it should be added as part of the
> connection parameter, and mentioned it a couple of days back:
> https://www.postgresql.org/message-id/CAB7nPqQAtKfG3H%2BuK11JNivtJtZYE9yVCrPuejRMjp8tUDe0nQ%40mail.g...
Attached is a patch as an attempt to bring together the best of both
worlds. The idea is to move the description of how the connection
parameter replication works from the replication protocol page into
the section of libpq dedicated to connection parameters, and add links
between both sections.
Thoughts?
--
Michael
Attachments:
[text/x-patch] replication-param-doc.patch (2.5K, 2-replication-param-doc.patch)
download | inline diff:
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 4703309254..09bfcbbec3 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -1222,6 +1222,24 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
</listitem>
</varlistentry>
+ <varlistentry id="libpq-connect-replication" xreflabel="replication">
+ <term><literal>replication</literal></term>
+ <listitem>
+ <para>
+ This option determines if a backend should use the replication
+ protocol. A Boolean value of <literal>true</literal> tells the backend
+ to go into walsender mode, wherein a small set of replication commands
+ can be issued instead of SQL statements. Only the simple query protocol
+ can be used in walsender mode. Passing <literal>database</literal>
+ as the value instructs walsender to connect to the database specified
+ in the <literal>dbname</literal> parameter, which will allow the
+ connection to be used for logical replication from that database.
+ For a detailed description about the replication protocol, consult
+ <xref linkend="protocol-replication"/>.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="libpq-connect-sslmode" xreflabel="sslmode">
<term><literal>sslmode</literal></term>
<listitem>
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8174e3defa..b85a3edda9 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -1630,15 +1630,9 @@ supported at the moment is <literal>tls-unique</literal>, defined in RFC 5929.
<para>
To initiate streaming replication, the frontend sends the
-<literal>replication</literal> parameter in the startup message. A Boolean value
-of <literal>true</literal> tells the backend to go into walsender mode, wherein a
-small set of replication commands can be issued instead of SQL statements. Only
-the simple query protocol can be used in walsender mode.
-Replication commands are logged in the server log when
+<xref linkend="libpq-connect-replication"/> connection parameter in the
+startup message. Replication commands are logged in the server log when
<xref linkend="guc-log-replication-commands"/> is enabled.
-Passing <literal>database</literal> as the value instructs walsender to connect to
-the database specified in the <literal>dbname</literal> parameter, which will allow
-the connection to be used for logical replication from that database.
</para>
<para>
For the purpose of testing replication commands, you can make a replication
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: libpq options
2017-11-22 13:27 libpq options [email protected]
2017-11-22 14:36 ` Re: libpq options Michael Paquier <[email protected]>
2017-11-25 10:05 ` Re: libpq options Michael Paquier <[email protected]>
@ 2017-11-28 08:00 ` Şahap Aşçı <[email protected]>
2017-11-28 08:21 ` Re: libpq options Michael Paquier <[email protected]>
1 sibling, 1 reply; 13+ messages in thread
From: Şahap Aşçı @ 2017-11-28 08:00 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: pgsql-docs; Fujii Masao <[email protected]>
I think this solves the consistency issue that i am talking about. Well, i
am just looking from documentation user point of view.
If it's developer only option and shouldn't be documented then maybe adding
a 'IDENTIFY_SYSTEM' parameter to pg_receivexlog is more appropriate.
like this pg_receivexlog ... --identify-system
On Sat, Nov 25, 2017 at 1:05 PM, Michael Paquier <[email protected]>
wrote:
> On Wed, Nov 22, 2017 at 11:36 PM, Michael Paquier
> <[email protected]> wrote:
> > Yeah, it is mainly a developer option which is why I guess it is not
> > documented. Like you, I think it should be added as part of the
> > connection parameter, and mentioned it a couple of days back:
> > https://www.postgresql.org/message-id/CAB7nPqQAtKfG3H%
> 2BuK11JNivtJtZYE9yVCrPuejRMjp8tUDe0nQ%40mail.gmail.com
>
> Attached is a patch as an attempt to bring together the best of both
> worlds. The idea is to move the description of how the connection
> parameter replication works from the replication protocol page into
> the section of libpq dedicated to connection parameters, and add links
> between both sections.
>
> Thoughts?
> --
> Michael
>
--
Şahap Aşçı
<https://tr.linkedin.com/in/sahapasci;
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: libpq options
2017-11-22 13:27 libpq options [email protected]
2017-11-22 14:36 ` Re: libpq options Michael Paquier <[email protected]>
2017-11-25 10:05 ` Re: libpq options Michael Paquier <[email protected]>
2017-11-28 08:00 ` Re: libpq options Şahap Aşçı <[email protected]>
@ 2017-11-28 08:21 ` Michael Paquier <[email protected]>
2018-01-09 16:53 ` Re: libpq options Vik Fearing <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: Michael Paquier @ 2017-11-28 08:21 UTC (permalink / raw)
To: Şahap Aşçı <[email protected]>; +Cc: pgsql-docs; Fujii Masao <[email protected]>
On Tue, Nov 28, 2017 at 5:00 PM, Şahap Aşçı <[email protected]> wrote:
> I think this solves the consistency issue that i am talking about. Well, i am just looking from documentation user point of view.
Thanks. Input is always welcome. I have added an entry in the commit
fest app so as this is not lost:
https://commitfest.postgresql.org/16/1387/
--
Michael
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: libpq options
2017-11-22 13:27 libpq options [email protected]
2017-11-22 14:36 ` Re: libpq options Michael Paquier <[email protected]>
2017-11-25 10:05 ` Re: libpq options Michael Paquier <[email protected]>
2017-11-28 08:00 ` Re: libpq options Şahap Aşçı <[email protected]>
2017-11-28 08:21 ` Re: libpq options Michael Paquier <[email protected]>
@ 2018-01-09 16:53 ` Vik Fearing <[email protected]>
0 siblings, 0 replies; 13+ messages in thread
From: Vik Fearing @ 2018-01-09 16:53 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Şahap Aşçı <[email protected]>; +Cc: pgsql-docs; Fujii Masao <[email protected]>
On 11/28/2017 09:21 AM, Michael Paquier wrote:
> On Tue, Nov 28, 2017 at 5:00 PM, Şahap Aşçı <[email protected]> wrote:
>> I think this solves the consistency issue that i am talking about. Well, i am just looking from documentation user point of view.
>
> Thanks. Input is always welcome. I have added an entry in the commit
> fest app so as this is not lost:
> https://commitfest.postgresql.org/16/1387/
I approve of this change.
Ready for Committer.
--
Vik Fearing +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: libpq options
2017-11-22 13:27 libpq options [email protected]
2017-11-22 14:36 ` Re: libpq options Michael Paquier <[email protected]>
2017-11-25 10:05 ` Re: libpq options Michael Paquier <[email protected]>
@ 2018-03-01 09:35 ` Andres Freund <[email protected]>
2018-03-02 01:50 ` Re: libpq options Michael Paquier <[email protected]>
2018-03-02 09:44 ` Re: libpq options Petr Jelinek <[email protected]>
1 sibling, 2 replies; 13+ messages in thread
From: Andres Freund @ 2018-03-01 09:35 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Petr Jelinek <[email protected]>; +Cc: [email protected]; pgsql-docs; Fujii Masao <[email protected]>
On 2017-11-25 19:05:54 +0900, Michael Paquier wrote:
> + <varlistentry id="libpq-connect-replication" xreflabel="replication">
> + <term><literal>replication</literal></term>
> + <listitem>
> + <para>
> + This option determines if a backend should use the replication
> + protocol.
"should"? The backend will, and the client will have to do so as well.
> A Boolean value of <literal>true</literal> tells the backend
> + to go into walsender mode, wherein a small set of replication commands
> + can be issued instead of SQL statements.
This actually is wrong now I think. Petr?
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: libpq options
2017-11-22 13:27 libpq options [email protected]
2017-11-22 14:36 ` Re: libpq options Michael Paquier <[email protected]>
2017-11-25 10:05 ` Re: libpq options Michael Paquier <[email protected]>
2018-03-01 09:35 ` Re: libpq options Andres Freund <[email protected]>
@ 2018-03-02 01:50 ` Michael Paquier <[email protected]>
2018-03-02 11:58 ` Re: libpq options Magnus Hagander <[email protected]>
1 sibling, 1 reply; 13+ messages in thread
From: Michael Paquier @ 2018-03-02 01:50 UTC (permalink / raw)
To: Andres Freund <[email protected]>; +Cc: Michael Paquier <[email protected]>; Petr Jelinek <[email protected]>; [email protected]; pgsql-docs; Fujii Masao <[email protected]>
On Thu, Mar 01, 2018 at 01:35:54AM -0800, Andres Freund wrote:
> On 2017-11-25 19:05:54 +0900, Michael Paquier wrote:
>> A Boolean value of <literal>true</literal> tells the backend
>> + to go into walsender mode, wherein a small set of replication commands
>> + can be issued instead of SQL statements.
>
> This actually is wrong now I think. Petr?
On more or less HEAD:
$ psql -X -d "replication=1 dbname=postgres"
postgres=# create table aa (a int);
ERROR: cannot execute SQL commands in WAL sender for physical replication
$ psql -X -d "replication=database dbname=postgres"
postgres=# create table aa (a int);
CREATE TABLE
So one needs to use replication=database in order to be able to issue
normal SQL statements, while replication=true enforces physical
replication where this cannot happen (no connection to a specified
database).
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: libpq options
2017-11-22 13:27 libpq options [email protected]
2017-11-22 14:36 ` Re: libpq options Michael Paquier <[email protected]>
2017-11-25 10:05 ` Re: libpq options Michael Paquier <[email protected]>
2018-03-01 09:35 ` Re: libpq options Andres Freund <[email protected]>
2018-03-02 01:50 ` Re: libpq options Michael Paquier <[email protected]>
@ 2018-03-02 11:58 ` Magnus Hagander <[email protected]>
2018-03-05 04:44 ` Re: libpq options Michael Paquier <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: Magnus Hagander @ 2018-03-02 11:58 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Andres Freund <[email protected]>; Michael Paquier <[email protected]>; Petr Jelinek <[email protected]>; Şahap Aşçı <[email protected]>; pgsql-docs; Fujii Masao <[email protected]>
On Fri, Mar 2, 2018 at 2:50 AM, Michael Paquier <[email protected]> wrote:
> On Thu, Mar 01, 2018 at 01:35:54AM -0800, Andres Freund wrote:
> > On 2017-11-25 19:05:54 +0900, Michael Paquier wrote:
> >> A Boolean value of <literal>true</literal> tells the backend
> >> + to go into walsender mode, wherein a small set of replication
> commands
> >> + can be issued instead of SQL statements.
> >
> > This actually is wrong now I think. Petr?
>
> On more or less HEAD:
> $ psql -X -d "replication=1 dbname=postgres"
> postgres=# create table aa (a int);
> ERROR: cannot execute SQL commands in WAL sender for physical replication
> $ psql -X -d "replication=database dbname=postgres"
> postgres=# create table aa (a int);
> CREATE TABLE
>
> So one needs to use replication=database in order to be able to issue
> normal SQL statements, while replication=true enforces physical
> replication where this cannot happen (no connection to a specified
> database).
>
To nitpick:
+ protocol. A Boolean value of <literal>true</literal> tells the
backend
We don't really have boolean values here, do we? It's just the string true
that's treated as a boolean by the backend. It just sounds really weird to
me when written that way. Particularly since the next sentence talks about
passing "database" as the same thing.
I know that's pretty much nitpicking, but I want to make sure I haven't
actually missed/forgotten how some part of that one is handled..
It also talks separately about "going into walsender mode" (=physical
replication) and "instructs the walsender to connect to the database". I
think that's a bit confusing. I suggest just calling it "physical
replication mode" and "logical replication mode", and not bother mentioning
walsender since that's quite internal.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/;
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: libpq options
2017-11-22 13:27 libpq options [email protected]
2017-11-22 14:36 ` Re: libpq options Michael Paquier <[email protected]>
2017-11-25 10:05 ` Re: libpq options Michael Paquier <[email protected]>
2018-03-01 09:35 ` Re: libpq options Andres Freund <[email protected]>
2018-03-02 01:50 ` Re: libpq options Michael Paquier <[email protected]>
2018-03-02 11:58 ` Re: libpq options Magnus Hagander <[email protected]>
@ 2018-03-05 04:44 ` Michael Paquier <[email protected]>
2018-03-07 02:05 ` Re: libpq options Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: Michael Paquier @ 2018-03-05 04:44 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: Andres Freund <[email protected]>; Michael Paquier <[email protected]>; Petr Jelinek <[email protected]>; Şahap Aşçı <[email protected]>; pgsql-docs; Fujii Masao <[email protected]>
On Fri, Mar 02, 2018 at 12:58:50PM +0100, Magnus Hagander wrote:
> To nitpick:
>
> + protocol. A Boolean value of <literal>true</literal> tells the
> backend
>
> We don't really have boolean values here, do we? It's just the string true
> that's treated as a boolean by the backend. It just sounds really weird to
> me when written that way. Particularly since the next sentence talks about
> passing "database" as the same thing.
>
> I know that's pretty much nitpicking, but I want to make sure I haven't
> actually missed/forgotten how some part of that one is handled..
Yes, that's indeed a bit inconsistent with the other parameters able to
use boolean-like parameters, like sslcompression or sslmode (deprecated
in favor requiressl), still those two ones are frontend-only
parameters, so they are just able to use "1" or "0". Replication is
part of the startup packet which uses parse_bool() so valid values can
be true, false, yes, no, on, off, 1 or 0. And it is even possible to
use upper-case characters. So why not documenting all that precisely
then?
> It also talks separately about "going into walsender mode" (=physical
> replication) and "instructs the walsender to connect to the database". I
> think that's a bit confusing. I suggest just calling it "physical
> replication mode" and "logical replication mode", and not bother mentioning
> walsender since that's quite internal.
Indeed, this term is pretty spread across the documentation as well.
I have taken into account this feedback, and created the new version
attached, for a v2.
Thoughts?
--
Michael
Attachments:
[text/x-diff] replication-param-doc-v2.patch (3.4K, 2-replication-param-doc-v2.patch)
download | inline diff:
diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml
index 2a8e1f2e07..8934559239 100644
--- a/doc/src/sgml/libpq.sgml
+++ b/doc/src/sgml/libpq.sgml
@@ -1262,6 +1262,57 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
</listitem>
</varlistentry>
+ <varlistentry id="libpq-connect-replication" xreflabel="replication">
+ <term><literal>replication</literal></term>
+ <listitem>
+ <para>
+ This option determines if a backend should use the replication
+ protocol. For a detailed description about the replication protocol,
+ consult <xref linkend="protocol-replication"/>. The following values,
+ which are case-insensitive, are supported:
+ <variablelist>
+ <varlistentry>
+ <term>
+ <literal>true</literal>, <literal>on</literal>,
+ <literal>yes</literal> or <literal>1</literal>
+ </term>
+ <listitem>
+ <para>
+ The backend goes into physical replication mode, wherein a small
+ set of replication commands can be issued instead of SQL statements.
+ Only the simple query protocol can be used in this case.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term><literal>database</literal></term>
+ <listitem>
+ <para>
+ The backend goes into logical replication mode, as the value
+ instructs the backend to connect to the database specified in
+ the <literal>dbname</literal> parameter. Only the simple query
+ protocol can be used in this case.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <literal>false</literal>, <literal>off</literal>,
+ <literal>no</literal> or <literal>0</literal>
+ </term>
+ <listitem>
+ <para>
+ The backend is a regular one, which is the default behavior.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="libpq-connect-sslmode" xreflabel="sslmode">
<term><literal>sslmode</literal></term>
<listitem>
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 3cec9e0b0c..2e231efac0 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -1635,15 +1635,9 @@ that cannot support <literal>tls-unique</literal> for some reason.
<para>
To initiate streaming replication, the frontend sends the
-<literal>replication</literal> parameter in the startup message. A Boolean value
-of <literal>true</literal> tells the backend to go into walsender mode, wherein a
-small set of replication commands can be issued instead of SQL statements. Only
-the simple query protocol can be used in walsender mode.
-Replication commands are logged in the server log when
+<xref linkend="libpq-connect-replication"/> connection parameter in the
+startup message. Replication commands are logged in the server log when
<xref linkend="guc-log-replication-commands"/> is enabled.
-Passing <literal>database</literal> as the value instructs walsender to connect to
-the database specified in the <literal>dbname</literal> parameter, which will allow
-the connection to be used for logical replication from that database.
</para>
<para>
For the purpose of testing replication commands, you can make a replication
[application/pgp-signature] signature.asc (833B, 3-signature.asc)
download
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: libpq options
2017-11-22 13:27 libpq options [email protected]
2017-11-22 14:36 ` Re: libpq options Michael Paquier <[email protected]>
2017-11-25 10:05 ` Re: libpq options Michael Paquier <[email protected]>
2018-03-01 09:35 ` Re: libpq options Andres Freund <[email protected]>
2018-03-02 01:50 ` Re: libpq options Michael Paquier <[email protected]>
2018-03-02 11:58 ` Re: libpq options Magnus Hagander <[email protected]>
2018-03-05 04:44 ` Re: libpq options Michael Paquier <[email protected]>
@ 2018-03-07 02:05 ` Peter Eisentraut <[email protected]>
2018-03-07 02:20 ` Re: libpq options Michael Paquier <[email protected]>
0 siblings, 1 reply; 13+ messages in thread
From: Peter Eisentraut @ 2018-03-07 02:05 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Magnus Hagander <[email protected]>; +Cc: Andres Freund <[email protected]>; Michael Paquier <[email protected]>; Petr Jelinek <[email protected]>; Şahap Aşçı <[email protected]>; pgsql-docs; Fujii Masao <[email protected]>
On 3/4/18 23:44, Michael Paquier wrote:
> I have taken into account this feedback, and created the new version
> attached, for a v2.
I didn't like so much shrinking down the protocol section. I have often
wanted *more* detail there, not less. So I combined your patch for the
libpq chapter and added a bit more in the protocol chapter as well.
Committed.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: libpq options
2017-11-22 13:27 libpq options [email protected]
2017-11-22 14:36 ` Re: libpq options Michael Paquier <[email protected]>
2017-11-25 10:05 ` Re: libpq options Michael Paquier <[email protected]>
2018-03-01 09:35 ` Re: libpq options Andres Freund <[email protected]>
2018-03-02 01:50 ` Re: libpq options Michael Paquier <[email protected]>
2018-03-02 11:58 ` Re: libpq options Magnus Hagander <[email protected]>
2018-03-05 04:44 ` Re: libpq options Michael Paquier <[email protected]>
2018-03-07 02:05 ` Re: libpq options Peter Eisentraut <[email protected]>
@ 2018-03-07 02:20 ` Michael Paquier <[email protected]>
0 siblings, 0 replies; 13+ messages in thread
From: Michael Paquier @ 2018-03-07 02:20 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Andres Freund <[email protected]>; Michael Paquier <[email protected]>; Petr Jelinek <[email protected]>; Şahap Aşçı <[email protected]>; pgsql-docs; Fujii Masao <[email protected]>
On Tue, Mar 06, 2018 at 09:05:38PM -0500, Peter Eisentraut wrote:
> I didn't like so much shrinking down the protocol section. I have often
> wanted *more* detail there, not less. So I combined your patch for the
> libpq chapter and added a bit more in the protocol chapter as well.
>
> Committed.
Thanks for the commit, my idea was to limit duplication between both
sections. If things get changed at some point, this avoids parts of the
documentation to rot.
<para>
-The commands accepted in walsender mode are:
+Replication commands are logged in the server log when
+<xref linkend="guc-log-replication-commands"/> is enabled.
+</para>
+
+<para>
+The commands accepted in replication mode are:
Good addition here.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 13+ messages in thread
* Re: libpq options
2017-11-22 13:27 libpq options [email protected]
2017-11-22 14:36 ` Re: libpq options Michael Paquier <[email protected]>
2017-11-25 10:05 ` Re: libpq options Michael Paquier <[email protected]>
2018-03-01 09:35 ` Re: libpq options Andres Freund <[email protected]>
@ 2018-03-02 09:44 ` Petr Jelinek <[email protected]>
1 sibling, 0 replies; 13+ messages in thread
From: Petr Jelinek @ 2018-03-02 09:44 UTC (permalink / raw)
To: Andres Freund <[email protected]>; Michael Paquier <[email protected]>; Petr Jelinek <[email protected]>; +Cc: [email protected]; pgsql-docs; Fujii Masao <[email protected]>
On 01/03/18 10:35, Andres Freund wrote:
> On 2017-11-25 19:05:54 +0900, Michael Paquier wrote:
>> + <varlistentry id="libpq-connect-replication" xreflabel="replication">
>> + <term><literal>replication</literal></term>
>> + <listitem>
>> + <para>
>> + This option determines if a backend should use the replication
>> + protocol.
>
> "should"? The backend will, and the client will have to do so as well.
>
I think so as well.
>
>> A Boolean value of <literal>true</literal> tells the backend
>> + to go into walsender mode, wherein a small set of replication commands
>> + can be issued instead of SQL statements.
>
> This actually is wrong now I think. Petr?
>
If the replication is true, we don't have database connection so only
replication commands can be executed.
SQL commands work when replication is set to database.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
^ permalink raw reply [nested|flat] 13+ messages in thread
end of thread, other threads:[~2018-03-07 02:20 UTC | newest]
Thread overview: 13+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2017-11-22 13:27 libpq options [email protected]
2017-11-22 14:36 ` Michael Paquier <[email protected]>
2017-11-25 10:05 ` Michael Paquier <[email protected]>
2017-11-28 08:00 ` Şahap Aşçı <[email protected]>
2017-11-28 08:21 ` Michael Paquier <[email protected]>
2018-01-09 16:53 ` Vik Fearing <[email protected]>
2018-03-01 09:35 ` Andres Freund <[email protected]>
2018-03-02 01:50 ` Michael Paquier <[email protected]>
2018-03-02 11:58 ` Magnus Hagander <[email protected]>
2018-03-05 04:44 ` Michael Paquier <[email protected]>
2018-03-07 02:05 ` Peter Eisentraut <[email protected]>
2018-03-07 02:20 ` Michael Paquier <[email protected]>
2018-03-02 09:44 ` Petr Jelinek <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox