Re: [Postgres-xc-developers] GTM updates

2012/7/11 Michael Paquier <mic...@gm...>:
> 1-6 have been committed.
> I just modified a couple of tiny places. Those were obviously serious bugs,
> and they have been backported to 1.0 branch.
>
> So, I also had a look at the 2 last patches.
>
> On Wed, Jul 11, 2012 at 5:20 AM, Andrei Martsinchyk
> <and...@gm...> wrote:
>>
>> 7 - we found the reconnect procedure in GTM proxy unnecessarily complex.
>> If GTM connection was lost it first was trying to reconnect to last known
>> GTM for configured period of time, then it waited for a "reconnect" command
>> for  another configured period of time, after it elapsed the GTM proxy
>> entered an invalid state, so attemt to issue "reconnect" command caused
>> program crash. We changed this, and now GTM proxy is trying to reconnect to
>> GTM infinitely. At any time host and port of the GTM to reconnect to may be
>> modified by issuing "reconnect" command. The only remaining configuration
>> parameter is the interval of time between reconnection attempt. Indeed, GTM
>> proxy is trying to reconnect again immediately after receiving the
>> "reconnect" command.

Hmm, this makes things much simpler while maintaining flexibility for
various installation.  Okay, we should go ahead.

> This looks simpler, indeed. And I like 2 things here:
> 1) Operation and setup gets better: elimination of 5 GUC params on Proxy
> side. The elimination of count-related parameters and retry really makes
> sense as GTM-proxy is only a connection bridge to GTM.
> 2) Operation gets simpler: GTM-Proxy operation becomes completely
> independant of the wait of a reconnect command, and won't put himself in an
> inconsistent state because of its settings. So you remove 1 degree of
> dependency here!
> I have however one comment regarding the patch:
> 1) In HandleGTMError, we try to reconnect with always the same
> gtm_connect_string set up outside the loop. If we receive a reconnect
> command while being in the loop gtm_connect_string will not get updated with
> the new values given by reconnect command for GTMServerHost and
> GTMServerPortNumber.
> So even while being inside the reconnection loop we will not get the latest
> connection parameters of GTM even if new things have been kicked to Proxy.
> Just to call, reconnect information has the following format (from docs):
> gtm_ctl reconnect -Z gtm_proxy -D datafolder_proxy -o '-s hostname -t
> port_number'
> Won't it make sense to generate gtm_connect_string inside the infinite for
> loop once longjump has been disabled?

I once thought an idea to use SIGHUP to reload
gtm.conf/gtm_proxy.conf.   This could be used in reconnect, as well as
many other on-the-fly configuration change, as done in PG.

This may end up with big change of the internal structure but may make
things much more simpler.

>> 8 - we changed format of the gtm.control file to text, so DBA do not need
>> a hex editor if it is needed to repair it manually in emergency case; it is
>> easier to notice corrupted gtm.control.

+1. Nice!

>
> This patch is also fixing whitespaces...
> Could it be possible to fix the format related problems into a separate
> patch such as I could also backport the format related problems in 1.0
> stable?
> The modification of the format of gtm.control is something that can only be
> pushed on master, so we need to divide correctly each thing we are fixing
> here.
>
> On the content of the patch, I don't have any arguments against such a
> feature. It might even facilitate operator's work by allowing him to change
> sequence infor manually.
> Some arguments here?
> --
> Michael Paquier
> http://michael.otacoo.com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>