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
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 ad
On Fri, Mar 02, 2018 at 12:58:50PM +0100, Magnus Hagander wrote:
> To nitpick:
>
> + protocol. A Boolean value of true 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
On Fri, Mar 2, 2018 at 2:50 AM, Michael Paquier 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 true tells the backend
> >> + to go into walsender mode, wherein a small set of replicatio
On 01/03/18 10:35, Andres Freund wrote:
> On 2017-11-25 19:05:54 +0900, Michael Paquier wrote:
>> +
>> + replication
>> +
>> +
>> + This option determines if a backend should use the replication
>> + protocol.
>
> "should"? The backend will, and the client will ha
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 true tells the backend
>> + to go into walsender mode, wherein a small set of replication
>> commands
>> + can be issued instead of SQL statements
On 2017-11-25 19:05:54 +0900, Michael Paquier wrote:
> +
> + replication
> +
> +
> + 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 true tel
On 11/28/2017 09:21 AM, Michael Paquier wrote:
> On Tue, Nov 28, 2017 at 5:00 PM, Şahap Aşçı 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 i
On Tue, Nov 28, 2017 at 5:00 PM, Şahap Aşçı 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://c
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_receivexlo
On Wed, Nov 22, 2017 at 11:36 PM, Michael Paquier
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/
uot;
> 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.p
l" 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 fin
13 matches
Mail list logo
