Re: [Postgres-xc-developers] gtm output and other gtm issues yet.

[Koichi S. <koi...@gm...>]

Hi,

2013/2/18 Nikhil Sontakke <ni...@st...>:
>> Thanks.   I tested the patch both on master and REL1_0_STABLE and found they look to work fine.  I will commit it to both branches.
>>
>
> Thanks Suzuki-san.
>
>> I found there are two more issues on GTM.
>>
>
> Yeah, these are very important from the correct functioning of the
> cluster. And both of them need to be tackled.
>
> And we need to think properly for a decent mechanism to do this.
> Specifically, the mechanism should not become a performance
> bottleneck. And yeah GTM WAL does seem to be an overkill.
>
> Maybe, we can have a GTM thread which writes the current GXID every
> 1000 increments. In case GTM dies and restarts in between, it can read
> the control file and start with the current value + 1000 as the next
> valid value.

Yes, I was thinking the same idea.   Number of increments can be a configuration
parameter.   Having dedicated thread could be a good idea which does not bring
too much overhead to GTM opeation.

>
> For sequences, again a similar mechanism can be though of. I admit I
> haven't looked at the current sequence handling. But we can introduce
> logic to track current saved value and current delta. Again if GTM
> dies and restarts, we can start with saved value + delta to be clear
> of existing sequence values.

Yes, exactly.   We should take sequence in to account too.   We need
simple mechanism to synchronize coordinator/datanode PITR and GTM
backup.   GTM has sufficient infrastructure to backup its own status.
 I'm thinking to extend Barrier mechanism to trigger this gtm.control
backup.

>
> Thoughts? Any other better suggestions?

Regards;
---
Koichi Suzuki

>
> Regards,
> Nikhils
>
>
>> 1) If we kill GTM process, GTM will begin to assing GXID values with the one of the proveious GTM run.  It is bad and harmful behaviour.   To improve it, GTM should write the next gxid value to gtm.control.   When gxid value reaches this backup, then the backup should be refreshed with the new one.   That way, we can safely restart GTM even if it was killed.   When GTM stops normally, it should write the next gxid value to gtm.control.
>>
>> 2) We have BARRIER to synchronize PITR recovery line.   However, GTM does not have this capability.  In this case, GTM's sequence definition could be inconsisitent if ALTER SEQUENCE or DROP SEQUENCE was issued after the recovery point.   Have WAL in GTM could be a general choice but it seems to be too much for current GTM feature.  Instead, we can have GTM.control backups when CREATE BARRIER is issued.   Backup files will be qualified by BARRIER id so that DBA can choose which backup to use at the end of PITR.
>>
>> Regards;
>> ---
>> Koichi
>>
>> On Sun, 17 Feb 2013 10:27:37 +0530
>> Nikhil Sontakke <ni...@st...> wrote:
>>
>>> Hi Suzuki-san,
>>>
>>> > It's so helpful to have this patch.   Will review and test it before committing.
>>> >
>>>
>>> Any comments on this patch? I do not see it in the commit logs.
>>>
>>> Regards,
>>> Nikhils
>>>
>>> > Best;
>>> > ---
>>> > Koichi Suzuki
>>> >
>>> > On Wed, 6 Feb 2013 14:25:48 +0530
>>> > Nikhil Sontakke <ni...@st...> wrote:
>>> >
>>> >> > Also, gtm_ctl -w option
>>> >> > seems not work properly.
>>> >> >
>>> >>
>>> >> PFA, a patch to fix "gtm_ctl -w" behavior in GIT HEAD. I also tested
>>> >> "-w -t nsecs" behavior and it seems to work as well. This patch can be
>>> >> easily be backported to 1.0 if desired. I hope all these obnoxious gtm
>>> >> startup issues are resolved now. Scripting was a bit painful because
>>> >> of these issues.
>>> >>
>>> >> Regards,
>>> >> Nikhils
>>> >>
>>> >> > I will take a look at these issue and fix at least in the next major
>>> >> > release.    Daemonization should be back-ported to 1.0.x.
>>> >> >
>>> >> > Kind Regards;
>>> >> > ----------
>>> >> > Koichi Suzuki
>>> >> >
>>> >> >
>>> >> > 2012/12/27 Michael Meskes <me...@po...>:
>>> >> >> I still haven't found the time to dig into this, but could anyone please
>>> >> >> explain to me how gtm is supposed to start up? A simple grep command doesn't
>>> >> >> seem to find any call to setsid() in gtm subdirs. Could you please point me to
>>> >> >> the code where gtm daemonizes? Because if it doesn't correctly, there is no
>>> >> >> suprise gtm_ctl doesn't come back. Or in other words, this is a logical point
>>> >> >> to start looking.
>>> >> >>
>>> >> >> Michael
>>> >> >> --
>>> >> >> Michael Meskes
>>> >> >> Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
>>> >> >> Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
>>> >> >> Jabber: michael.meskes at gmail dot com
>>> >> >> VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
>>> >> >>
>>> >> >> ------------------------------------------------------------------------------
>>> >> >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>>> >> >> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
>>> >> >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
>>> >> >> MVPs and experts. ON SALE this month only -- learn more at:
>>> >> >> http://p.sf.net/sfu/learnmore_122712
>>> >> >> _______________________________________________
>>> >> >> 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
>>>
>>>
>>>
>>> --
>>> StormDB - http://www.stormdb.com
>>> The Database Cloud
>>> Postgres-XC Support and Service
>>>
>
>
>
> --
> StormDB - http://www.stormdb.com
> The Database Cloud
> Postgres-XC Support and Service