On Saturday, January 19, 2013 5:49 PM Magnus Hagander wrote:
>On Fri, Jan 18, 2013 at 1:05 PM, Heikki Linnakangas
><hlinnakangas@vmware.com> wrote:
>> On 18.01.2013 13:41, Amit Kapila wrote:
>>>
>>> On Friday, January 18, 2013 3:46 PM Heikki Linnakangas wrote:
>>>>
>>>> On 18.01.2013 08:50, Amit Kapila wrote:
>>> So to solve this problem below can be done:
>>> 1. Support connection string in pg_basebackup and mention keepalives or
>>> connection_timeout
>>> 2. Support recv_timeout separately to provide a way to users who are not
>>> comfortable tcp keepalives
>>>
>>> a. 1 can be done alone
>>> b. 2 can be done alone
>>> c. both 1 and 2.
>>
>>
>> Right. Let's do just 1 for now. An general application level, non-TCP,
>> keepalive message at the libpq level might be a good idea, but that's a
much
>> larger patch, definitely not 9.3 material.
>
>+1 for doing 1 now. But actually, I think we can just keep it that way
>in the future as well. If you need to specify these fairly advanced
>options, using a connection string really isn't a problem.
>
>I think it would be more worthwhile to go through the rest of the
>tools in bin/ and make sure they *all* support connection strings.
>And, an important point, do it the same way.
Presently I am trying to implement the option-1 by adding an extra command
line
Option -C "connection_string" to pg_basebackup and pg_receivexlog.
This option can be used with all the tools in bin folder.
The existing command line options to the tools are not planned to remove as
of now.
To handle both options, we can follow these approaches.
1. To make the code simpler, the connection string is formed inside with the
existing
command line options, if the user is not provided the "connection_string"
option.
which is used for further processing.
2. The connection_string and existing command line options are handled
separately.
I feel approach-1 is better. Please provide your suggestions on the same.
Regards,
Hari babu.