Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eJapC-0001yV-4D for pgsql-docs@arkaria.postgresql.org; Tue, 28 Nov 2017 08:01:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eJapA-0000w0-LW for pgsql-docs@arkaria.postgresql.org; Tue, 28 Nov 2017 08:01:00 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eJapA-0000vq-Ai for pgsql-docs@lists.postgresql.org; Tue, 28 Nov 2017 08:01:00 +0000 Received: from mail-lf0-x244.google.com ([2a00:1450:4010:c07::244]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eJaoy-0006Ef-QG for pgsql-docs@postgresql.org; Tue, 28 Nov 2017 08:00:58 +0000 Received: by mail-lf0-x244.google.com with SMTP id o41so35839556lfi.2 for ; Tue, 28 Nov 2017 00:00:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LKWn7fzCLX1ql4sCu91vTZOlIIhGg3tnTMKCPcIHND8=; b=ODphs2ibEQpavVkoWIouOcqlofwM2XRWX+Jp54iII7yeVqbPwpmjJapwqGQeEmf+6M hf7uZIy778BmodbshnVtpQyu3W4TEIkWnMVWdy5uGvKQ541k6LTtTMaZUOXWMovB8kyZ fbKIeUdBry9XJJTkSuOVtu0xMHnLqQPumjxBGslT+31vMv1oeyM4uAqtu0TiSlgWdU6P 30WP8008udfggfDU8yi/ZX/IJXR8FuVG2Wi7CTEEdHUQPVB8rWTCPRWYbLL07kqzbCGM LFv5/ufNM3uunm8El5/D1wWEUVox+2xDgcd1FZ2orOJM/NCb0uwNinmiDSwqU9/N/oWj s5KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LKWn7fzCLX1ql4sCu91vTZOlIIhGg3tnTMKCPcIHND8=; b=UlHg6pYT4P37y3tmqJEyscq6wwbvM/2iLq9KdBK72xFV0gUfAYO/9NU2S/A1sjPYyr yd3E/Yh+X9uTK88pA2Wa0tNb05WsU51b7vKWcJ9z6rLp4hOHsr9FIw03bdr0CyfAUzjc AfOGBKjNOLCiHablB9u6ppZjFMHQ4LGQPuoXjIoNRR6uhaPx+az4EN8NmKYLvgQG2oWT L2fmxZdDWlm4fUs/ugY/QzCcMzgYfcn5MdrCmHl7i5dm3jKmpfTKme/gR7SvWFQzD0sQ l7HMvEZ09XCPs+tBHgMn4VV70Bm8qMpuO6bdBduYv8Han9XIVa+cAT1i0T9UiNyfSuvs hZiQ== X-Gm-Message-State: AJaThX4x9YUW7D7wFd60WXkaHzRyql4eueFvBZNkM8L+I6MOeZxQDqy+ bnm3ABrly7qyCfZexePumSkOBH3kQrg/vxhfT/Q= X-Google-Smtp-Source: AGs4zMZJo3r0lhNJEXflTzT/kioH6A6uCpgugufvqIma/6mTHHWUWCgVFbvxx/Gkrcm/CQQggHAOVbYlNMPyLsuMgXY= X-Received: by 10.46.88.77 with SMTP id x13mr15798865ljd.80.1511856044819; Tue, 28 Nov 2017 00:00:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.99.13 with HTTP; Tue, 28 Nov 2017 00:00:14 -0800 (PST) In-Reply-To: References: <20171122132714.1463.27247@wrigleys.postgresql.org> From: =?UTF-8?B?xZ5haGFwIEHFn8OnxLE=?= Date: Tue, 28 Nov 2017 11:00:14 +0300 Message-ID: Subject: Re: libpq options To: Michael Paquier Cc: pgsql-docs@postgresql.org, Fujii Masao Content-Type: multipart/alternative; boundary="f4030438f0f080c93a055f066aec" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --f4030438f0f080c93a055f066aec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > 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/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 > --=20 =C5=9Eahap A=C5=9F=C3=A7=C4=B1 --f4030438f0f080c93a055f066aec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this solves the consistency issue that i am t= alking about. Well, i am just looking from documentation user point of view= .

If it's developer only option and shoul= dn't be documented then maybe adding a 'IDENTIFY_SYSTEM' parame= ter to pg_receivexlog is more appropriate.
like this pg_rece= ivexlog ...=C2=A0 --identify-system






On Sat, Nov 25, 2017 at 1:05 PM, Michael Paquier <michael.paquier= @gmail.com> wrote:
On Wed, Nov 22, 2017 at 11:36 PM, Michael= Paquier
<michael.paquier@gmail.com<= /a>> 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



--
=C5=9Eahap A=C5=9F=C3=A7=C4=B1
=3D""
--f4030438f0f080c93a055f066aec--