Re: [Postgres-xc-developers] Separate GTM configuration part in gtm/common into a separate folder

On 2012/10/29, at 21:14, Nikhil Sontakke <ni...@st...> wrote:

> I have found writing -Z GTM/GTM_STANDY/GTM_PROXY as part of the cli pretty painful. 
> 
> Infact there's not much difference between GTM and GTM_STANDBY at all in terms of processing from the front end. Also I am not sure why we have gtm_proxy.conf for the proxy and gtm.conf for GTM and the STANDBY. 
> 
> Like pg, where starting a replica has the same cli as starting the pg server, we should have had the same here for all the cases and should have allowed the role be picked up from the contents of the gtm.conf file. 
> 
> One area where would this pain is in HA. Typical HA configs expect same directory structures across the nodes and the same clis to start the resources etc. Now adding additional logic to include "-Z gtm/standby/proxy" introduces additional pain in this. 
Thanks for those arguments, but here my goal is to clean up the code and facilitate maintenance. I am not planning to change the current configuration specs.

> 
> My 2 cents.
> 
> Regards,
> Nikhils
> 
> On Mon, Oct 29, 2012 at 5:29 PM, Michael Paquier <mic...@gm...> wrote:
> 
> 
> On Mon, Oct 29, 2012 at 7:19 PM, Ashutosh Bapat <ash...@en...> wrote:
> Thanks for taking this up.
> 
> On Mon, Oct 29, 2012 at 3:08 PM, Michael Paquier <mic...@gm...> wrote:
> Hi all,
> 
> I am currently working on cleaning up the dependencies and duplications that GTM code has.
> This is a pretty complicated task, as GTM has many code duplication with libpq and also src/backend.
> 
> By the way, I am trying to do this clean up with a maximum number of discrete steps, making the progression clear. One of the things I noticed is related to the GTM configuration system. It is a duplication of what can be found in guc.c. However, guc.c is used exclusively by PG backend and all its structures remain internal to GUC. In the case of GTM, those APIs are used by both GTM and GTM-proxy as they both use a configuration file, so GTM configuration APIs need to be externalized to avoid duplication between the things used by GTM and by GTM-proxy. As far as I saw, there is no way to resolve the PG-GUC/GTM conf duplication as we would need to externalize all the structures in guc.c.
> However, the GTM configuration APIs are located in src/gtm/common, which generates an archive called libgtm.a, this archive being used by src/backend for the construction of the binary file postgres. We need to remove this dependency between the GTM configuration and PG backend for clarity, so please find attached a patch that moves the GTM configuration APIs into a new folder src/gtm/config and avoids a useless dependency of this code with PG backend.
> 
> On using guc.c, is there a separation of (I haven't looked at the file itself) separate the datastructures (the array where GUCs and there values are stored or fetched from etc.) and functions exposed. If so, we might copy the data structures but leave the functions common to PG and GTM. Are there any other tools in PG code which also require a configuration file and share the guc interfaces.
> Each configuration file in PG uses a different structure, with GUC being the most complex.
> For example recovery.conf uses readRecoveryCommandFile in xlog.c, postgresql.conf uses guc.c. ident.conf and pg_hba.conf also use something different (didn't have a look where but it is easy to find out). However, regarding the GUC part, there is an interface available with guc-file.l. In this file there are functions that GTM is duplicating and we should definitely to use that (functions like ProcessConfigFile or ParseConfigFile for example). Please note that they may need some extension as the existing functions are designed only for src/backend as far as I saw. The ultimate goal would be to use those APIs also with GTM for the configuration part, and to keep the list of parameters in GTM. Before reaching that point I want to reduce the dependencies between GTM modules to understand how to untie one by one all the duplications that GTM has with things like memory, list, configuration, StringInfo, Assert, etc.
> Even before untying everything there are a couple of things missing for this work:
> - change the Makefile structure in GTM to avoid relying on static archives and reach the same state as src/backend that use for example objfiles.txt. I have basically a patch, just need to clean it up
> - move gtm_ctl out of src/gtm to src/bin, also got a patch here, but it needs a little bit more work to have clean makefiles.
> -- 
> Michael Paquier
> http://michael.otacoo.com
> 
> ------------------------------------------------------------------------------
> The Windows 8 Center - In partnership with Sourceforge
> Your idea - your app - 30 days.
> Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
> 
> 
> 
> 
> -- 
> StormDB - http://www.stormdb.com
> The Database Cloud
> Postgres-XC Support and Service