From: Nikhil S. <ni...@st...> - 2013-09-16 11:41:11
|
Hi, One of our customers reported the following issue on the Standby: 1:140638715778816:2013-09-13 07:08:11.351 EDT -ERROR: GTM_TransactionInfo already in use. Cannot assign the transaction: handle (3745). I investigated this and thought I had fixed this with the patch that I have provided on the thread with $SUBJECT (Issues with GTM Standby Syncup) That patch reduced the number of these messages, but yet, some still found their way into the Standby logs. What's happening is that GTM Standby as part of the initial syncup with the GTM, sends gtm_standby_end_backup() after which the main GTM activates all the threads which had been paused earlier for the syncup. In the time between Standby calls the above function and actually starts listening for incoming data, some packets from the GTM are lost. Remember this will be the case when the GTM is already very highly loaded and lots of threads are running. If these packets contain commit info for those GXIDs that were added in the initial syncup, then they are lost and as a result these slots do not get cleaned up at the standby causing the above error messages. I think the best fix would be to delay and send gtm_standby_end_backup() inside the Serverloop, JUST before the Standby is going to do the select() call. Am trying a patch on similar lines but getting some issues, will get back with a patch soon. Regards, Nikhils -- StormDB - http://www.stormdb.com The Database Cloud |
From: Koichi S. <koi...@gm...> - 2013-09-17 02:47:36
|
I've got the issue. Yes, this is what I was concerning about and I appreciate for finding the issue and possible cause. How much you're in a hurry? I'm now in Chicago for Postgres Open and might not have a time to look into it until I finish my presentation tomorrow. Regards; --- Koichi Suzuki 2013/9/16 Nikhil Sontakke <ni...@st...> > Hi, > > One of our customers reported the following issue on the Standby: > > 1:140638715778816:2013-09-13 07:08:11.351 EDT -ERROR: GTM_TransactionInfo > already in use. Cannot assign the transaction: handle (3745). > > I investigated this and thought I had fixed this with the patch that I > have provided on the thread with $SUBJECT (Issues with GTM Standby Syncup) > > That patch reduced the number of these messages, but yet, some still found > their way into the Standby logs. > > What's happening is that GTM Standby as part of the initial syncup with > the GTM, sends gtm_standby_end_backup() after which the main GTM activates > all the threads which had been paused earlier for the syncup. > > In the time between Standby calls the above function and actually starts > listening for incoming data, some packets from the GTM are lost. Remember > this will be the case when the GTM is already very highly loaded and lots > of threads are running. > > If these packets contain commit info for those GXIDs that were added in > the initial syncup, then they are lost and as a result these slots do not > get cleaned up at the standby causing the above error messages. > > I think the best fix would be to delay and send gtm_standby_end_backup() > inside the Serverloop, JUST before the Standby is going to do the select() > call. Am trying a patch on similar lines but getting some issues, will get > back with a patch soon. > > Regards, > Nikhils > -- > StormDB - http://www.stormdb.com > The Database Cloud > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > |