You can subscribe to this list here.
2010 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(17) |
Jun
(3) |
Jul
|
Aug
|
Sep
(8) |
Oct
(18) |
Nov
(51) |
Dec
(74) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
(47) |
Feb
(44) |
Mar
(44) |
Apr
(102) |
May
(35) |
Jun
(25) |
Jul
(56) |
Aug
(69) |
Sep
(32) |
Oct
(37) |
Nov
(31) |
Dec
(16) |
2012 |
Jan
(34) |
Feb
(127) |
Mar
(218) |
Apr
(252) |
May
(80) |
Jun
(137) |
Jul
(205) |
Aug
(159) |
Sep
(35) |
Oct
(50) |
Nov
(82) |
Dec
(52) |
2013 |
Jan
(107) |
Feb
(159) |
Mar
(118) |
Apr
(163) |
May
(151) |
Jun
(89) |
Jul
(106) |
Aug
(177) |
Sep
(49) |
Oct
(63) |
Nov
(46) |
Dec
(7) |
2014 |
Jan
(65) |
Feb
(128) |
Mar
(40) |
Apr
(11) |
May
(4) |
Jun
(8) |
Jul
(16) |
Aug
(11) |
Sep
(4) |
Oct
(1) |
Nov
(5) |
Dec
(16) |
2015 |
Jan
(5) |
Feb
|
Mar
(2) |
Apr
(5) |
May
(4) |
Jun
(12) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
1
|
2
|
3
|
4
|
5
|
6
|
7
(13) |
8
(8) |
9
(12) |
10
(10) |
11
|
12
(1) |
13
(19) |
14
|
15
(22) |
16
(6) |
17
(20) |
18
|
19
|
20
(1) |
21
(1) |
22
(3) |
23
(4) |
24
(9) |
25
|
26
|
27
(4) |
28
(10) |
29
(3) |
30
(3) |
31
(2) |
|
From: 鈴木 幸市 <ko...@in...> - 2013-05-15 05:31:25
|
Here's the second fix. Regards; --- Koichi Suzuki On 2013/05/15, at 13:22, Ashutosh Bapat <ash...@en...> wrote: > Again in this case, the right fix is to use the standard EXPLAIN form EXPLAIN (verbose, num_nodes off, nodes off, costs off). > > What I don't understand is how come these changes appeared suddenly? > > > On Wed, May 15, 2013 at 7:59 AM, Koichi Suzuki <koi...@gm...> wrote: > Hello; > > This failure was caused by the following: > > 1. Now FQS pushes down order by and there're no sort at coordinator. Current regression did not reflect this. > > 2. Regression test changed the datanode name. Current regression did not reflect this. > > Enclosed is a fix. > > Regards; > ---------- > Koichi Suzuki > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Postgres Database Company > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d_______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers |
From: 鈴木 幸市 <ko...@in...> - 2013-05-15 05:10:36
|
Do you mean we should take xc_sort.sql from older release? --- Koichi Suzuki On 2013/05/15, at 13:22, Ashutosh Bapat <ash...@en...> wrote: > Again in this case, the right fix is to use the standard EXPLAIN form EXPLAIN (verbose, num_nodes off, nodes off, costs off). > > What I don't understand is how come these changes appeared suddenly? > > > On Wed, May 15, 2013 at 7:59 AM, Koichi Suzuki <koi...@gm...> wrote: > Hello; > > This failure was caused by the following: > > 1. Now FQS pushes down order by and there're no sort at coordinator. Current regression did not reflect this. > > 2. Regression test changed the datanode name. Current regression did not reflect this. > > Enclosed is a fix. > > Regards; > ---------- > Koichi Suzuki > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Postgres Database Company > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d_______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers |
From: Ashutosh B. <ash...@en...> - 2013-05-15 04:22:13
|
Again in this case, the right fix is to use the standard EXPLAIN form EXPLAIN (verbose, num_nodes off, nodes off, costs off). What I don't understand is how come these changes appeared suddenly? On Wed, May 15, 2013 at 7:59 AM, Koichi Suzuki <koi...@gm...>wrote: > Hello; > > This failure was caused by the following: > > 1. Now FQS pushes down order by and there're no sort at coordinator. > Current regression did not reflect this. > > 2. Regression test changed the datanode name. Current regression did not > reflect this. > > Enclosed is a fix. > > Regards; > ---------- > Koichi Suzuki > > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Postgres Database Company |
From: Ashutosh B. <ash...@en...> - 2013-05-15 04:17:29
|
That's not a correct fix. We should turn off the node count in Explain output. Use EXPLAIN (verbose, num_nodes off, nodes off, costs off) as a general rule. In case of single node reduction tests, we may use num_nodes on, but in that case num_nodes will always be 1, and will not change depending upon cluster configuration. On Wed, May 15, 2013 at 7:56 AM, Koichi Suzuki <koi...@gm...>wrote: > I found the regression failure was due to the change of explain output. > Original expected output uses node count = 3, which is not correct because > regression test is configured with only two datanode. Actual result says > node count = 2 which is correct. > > Attached is a patch for the correction. > > Regards; > ---------- > Koichi Suzuki > > > ------------------------------------------------------------------------------ > AlienVault Unified Security Management (USM) platform delivers complete > security visibility with the essential security capabilities. Easily and > efficiently configure, manage, and operate all of your security controls > from a single console and one unified framework. Download a free trial. > http://p.sf.net/sfu/alienvault_d2d > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Postgres Database Company |
From: Abbas B. <abb...@en...> - 2013-05-15 00:49:57
|
The patch worked fine for me and the changes in the SQL and expected output are good to go. On Fri, May 10, 2013 at 2:21 PM, Ashutosh Bapat < ash...@en...> wrote: > Hi All, > Here is regression fix for tsearch.sql. > > There were 2 alt expected outputs added (for no reason, I could see). > ORDER BY clause was previously added to the queries in SQL file, but the > ouptuts were only updated in alt output file. That's worst way of fixing > output ordering. Fixed it in this patch. I have removed alternate output > files. > > There was a unique index being created on a table. It was failing because > the default distribution in distributed (vs replicated). I have changed the > distribution to replicated and error is gone. > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Postgres Database Company > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > -- -- *Abbas* Architect Ph: 92.334.5100153 Skype ID: gabbasb www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/> * Follow us on Twitter* @EnterpriseDB Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community> |
From: Abbas B. <abb...@en...> - 2013-05-15 00:01:23
|
Adding developers mailing list. On Wed, May 15, 2013 at 4:57 AM, Abbas Butt <abb...@en...>wrote: > Hi, > Attached please find a patch to fix test case with. > There were two issues making the test to fail. > 1. Updates to partition column were possible using syntax like > WITH t AS (UPDATE y SET a=a+1 RETURNING *) SELECT * FROM t > The patch blocks this syntax. > > 2. For a WITH query that updates a table in the main query and > inserts a row in the same table in the WITH query we need to use > command ID communication to remote nodes in order to > maintain global data visibility. > For example > CREATE TEMP TABLE tab (id int,val text) DISTRIBUTE BY REPLICATION; > INSERT INTO tab VALUES (1,'p1'); > WITH wcte AS (INSERT INTO tab VALUES(42,'new') RETURNING id AS newid) > UPDATE tab SET id = id + newid FROM wcte; > The last query gets translated into the following multi-statement > transaction on the primary datanode > (a) START TRANSACTION ISOLATION LEVEL read committed READ WRITE > (b) INSERT INTO tab (id, val) VALUES ($1, $2) RETURNING id -- > (42,'new)' > (c) SELECT id, val, ctid FROM ONLY tab WHERE true > (d) UPDATE ONLY tab tab SET id = $1 WHERE (tab.ctid = $3) -- > (43,(0,1)] > (e) COMMIT TRANSACTION > The command id of the select in step (c), should be such that > it does not see the insert of step (b) > > Comments are welcome. > > Regards > > -- > *Abbas* > Architect > > Ph: 92.334.5100153 > Skype ID: gabbasb > www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/> > * > Follow us on Twitter* > @EnterpriseDB > > Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community> > -- -- *Abbas* Architect Ph: 92.334.5100153 Skype ID: gabbasb www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/> * Follow us on Twitter* @EnterpriseDB Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community> |
From: Abbas B. <abb...@en...> - 2013-05-15 00:00:48
|
Adding developers mailing list. On Wed, May 15, 2013 at 4:51 AM, Abbas Butt <abb...@en...>wrote: > Hi, > PFA a patch to change names of a couple of variable to more general names. > This patch touches some of the areas of command id exchange mechanism > between nodes of the cluster and we can use this thread to discuss whether > we need to enable command id exchange in all cases OR not. > For reference see the patch 38b2b79 committed by Michael for the rest of > the details of the mechanism. > > -- > *Abbas* > Architect > > Ph: 92.334.5100153 > Skype ID: gabbasb > www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/> > * > Follow us on Twitter* > @EnterpriseDB > > Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community> > -- -- *Abbas* Architect Ph: 92.334.5100153 Skype ID: gabbasb www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/> * Follow us on Twitter* @EnterpriseDB Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community> |
From: Koichi S. <koi...@gm...> - 2013-05-13 11:36:44
|
I reviewed patches and tested them. The patch look reasonable and does not influence the regression. Because these patches are submitted four days ago and everybody had good amount of time to think about it, I think it safe to commit it now. Please respond to me in an hour if you have any further inputs to this. Regards; ---------- Koichi Suzuki 2013/5/9 Andrei Martsinchyk <and...@gm...> > Hi, > > We have found few bugs related to GTM standby. > 1. Missing break; after handling MSG_BKUP_TXN_BEGIN_GETGXID on standby was > causing error > "insufficient data left in message". Patch is attached. > 2. GTM master does not forward information about sequence created to > standby. Patch is attached, too. > 3. When restarting cluster with standby, GTM master logs errors "Expecting > a startup message, but received �". The problem disappears if I remove file > register.node from the GTM master data directory. Before I start looking > into details, why GTM needs to save information about running nodes? > Cluster may be shut down for reconfiguration and information in > register.node may be out of date. At the same time when nodes connect to > GTM they deliver actual information. > So, maybe proper fix for the problem is just to remove code to > save/restore register.node? > > -- > Andrei Martsinchyk > > StormDB - http://www.stormdb.com > The Database Cloud > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > |
From: 鈴木 幸市 <ko...@in...> - 2013-05-13 10:55:17
|
Thanks. Then we will keep the commit. --- Koichi Suzuki On 2013/05/13, at 19:33, Abbas Butt <abb...@en...> wrote: > I think Amit just suggested we can use some other means that provide similar functionality to execute advisory lock commands on a particular node. This is totally independent of what I just committed. There is no conflicting requirement. > > On Mon, May 13, 2013 at 3:19 PM, Koichi Suzuki <koi...@gm...> wrote: > Hello; > > > I found the patch by Abbas was committed. Amit, how does it conflict with your requirement? Do you have any idea how to resolve this? > > I'm not sure if not using execute direct solves this conflicting requirement. > > Regards; > > ---------- > Koichi Suzuki > > > 2013/5/13 鈴木 幸市 <ko...@in...> > I'm okay with either case. I can stop the master until all the coordinator issues DROP NODE and then if the following feature is available, I can exchange the order (of course, stopping the master first is safer and more flexible). > > Could somebody check if Michael's patch is available? > > Regards; > --- > Koichi Suzuki > > > > On 2013/05/13, at 17:28, Amit Khandekar <ami...@en...> wrote: > >> >> >> On 13 May 2013 11:52, Abbas Butt <abb...@en...> wrote: >> >> >> On Mon, May 13, 2013 at 10:52 AM, Ashutosh Bapat <ash...@en...> wrote: >> Hi Abbas, >> Why is DROP NODE executing EXEC DIRECT ON? The internal code shouldn't do this. EXEC DIRECT is only for debug purposes and can be deprecated in future. In fact, I am leaning to remove it. It's complicating matters a lot. >> >> DROP NODE does not issue EXECUTE DIRECT, it tries to acquire an advisory lock and our implementation of advisory lock uses EXEC DIRECT. Please take a look at the function pgxc_advisory_lock. Amit can explain it more. >> >> In order to send pg_advisory_lock() in serial manner, one each of the node one after the other, I had to do this. I guess Michael has now written some helper functions to execute commands on particular node, which we can use instead of exec_direct. >> >> >> >> >> On Mon, May 13, 2013 at 11:03 AM, Abbas Butt <abb...@en...> wrote: >> >> >> On Mon, May 13, 2013 at 9:31 AM, Koichi Suzuki <koi...@gm...> wrote: >> Hello; >> >> I'm testing pgxc_ctl to remove a coordinator master. Following your suggestions, I first stopped the coordinator master to be removed and then issued "drop node" in all the other coordinators. Somehow drop node complains that it fails to obtain pooled connection, in fact, in drop node, "execute direct on (node_to_be_removed)" was issued. >> >> It worked fine if the removed coordinator is stopped after all the DROP NODE are successful. >> >> Did you issue CLEAN CONNECTION or pgxc_pool_reload before you issue "DROP NODE"? >> >> No, I did not issue any such statement. I just tested again and I am also getting the following error when I issue DROP NODE >> test=# drop node coord_2; >> ERROR: Failed to get pooled connections >> CONTEXT: SQL statement "EXECUTE DIRECT ON (coord_2) 'SELECT pg_catalog.pg_try_advisory_xact_lock_shared(65535, 0)'" >> test=# >> >> This is a bug and has to be fixed. The bug is that DROP NODE should not be trying to acquire the lock. I will send a fix for this today. The steps remain the same as before. >> >> >> >> Regards; >> ---------- >> Koichi Suzuki >> >> >> >> -- >> -- >> Abbas >> Architect >> >> Ph: 92.334.5100153 >> Skype ID: gabbasb >> www.enterprisedb.com >> >> Follow us on Twitter >> @EnterpriseDB >> >> Visit EnterpriseDB for tutorials, webinars, whitepapers and more >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and >> their applications. This 200-page book is written by three acclaimed >> leaders in the field. The early access version is available now. >> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may >> _______________________________________________ >> Postgres-xc-developers mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers >> >> >> >> >> -- >> Best Wishes, >> Ashutosh Bapat >> EntepriseDB Corporation >> The Postgres Database Company >> >> >> >> -- >> -- >> Abbas >> Architect >> >> Ph: 92.334.5100153 >> Skype ID: gabbasb >> www.enterprisedb.com >> >> Follow us on Twitter >> @EnterpriseDB >> >> Visit EnterpriseDB for tutorials, webinars, whitepapers and more >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and >> their applications. This 200-page book is written by three acclaimed >> leaders in the field. The early access version is available now. >> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may >> _______________________________________________ >> Postgres-xc-developers mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers >> >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and >> their applications. This 200-page book is written by three acclaimed >> leaders in the field. The early access version is available now. >> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may_______________________________________________ >> Postgres-xc-developers mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > > > > -- > -- > Abbas > Architect > > Ph: 92.334.5100153 > Skype ID: gabbasb > www.enterprisedb.com > > Follow us on Twitter > @EnterpriseDB > > Visit EnterpriseDB for tutorials, webinars, whitepapers and more |
From: Michael M. <me...@po...> - 2013-05-13 10:38:43
|
Hi, I just noted that the 1.0.3 release notes have a typo or better are missing a line. Patch attached. While looking for this I noticed that git HEAD as well as REL_1_1_STABLE have no 1.0.3 section in the release notes. I haven't checked for the other changes, but I wonder if this is an oversight or there is a reason for not including it. 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 |
From: Abbas B. <abb...@en...> - 2013-05-13 10:33:59
|
I think Amit just suggested we can use some other means that provide similar functionality to execute advisory lock commands on a particular node. This is totally independent of what I just committed. There is no conflicting requirement. On Mon, May 13, 2013 at 3:19 PM, Koichi Suzuki <koi...@gm...>wrote: > Hello; > > > I found the patch by Abbas was committed. Amit, how does it conflict > with your requirement? Do you have any idea how to resolve this? > > I'm not sure if not using execute direct solves this conflicting > requirement. > > Regards; > > ---------- > Koichi Suzuki > > > 2013/5/13 鈴木 幸市 <ko...@in...> > >> I'm okay with either case. I can stop the master until all the >> coordinator issues DROP NODE and then if the following feature is >> available, I can exchange the order (of course, stopping the master first >> is safer and more flexible). >> >> Could somebody check if Michael's patch is available? >> >> Regards; >> --- >> Koichi Suzuki >> >> >> >> On 2013/05/13, at 17:28, Amit Khandekar <ami...@en...> >> wrote: >> >> >> >> On 13 May 2013 11:52, Abbas Butt <abb...@en...> wrote: >> >>> >>> >>> On Mon, May 13, 2013 at 10:52 AM, Ashutosh Bapat < >>> ash...@en...> wrote: >>> >>>> Hi Abbas, >>>> Why is DROP NODE executing EXEC DIRECT ON? The internal code shouldn't >>>> do this. EXEC DIRECT is only for debug purposes and can be deprecated in >>>> future. In fact, I am leaning to remove it. It's complicating matters a lot. >>>> >>> >>> DROP NODE does not issue EXECUTE DIRECT, it tries to acquire an advisory >>> lock and our implementation of advisory lock uses EXEC DIRECT. Please take >>> a look at the function pgxc_advisory_lock. Amit can explain it more. >>> >> >> In order to send pg_advisory_lock() in serial manner, one each of the >> node one after the other, I had to do this. I guess Michael has now written >> some helper functions to execute commands on particular node, which we can >> use instead of exec_direct. >> >> >>> >>> >>>> >>>> >>>> On Mon, May 13, 2013 at 11:03 AM, Abbas Butt < >>>> abb...@en...> wrote: >>>> >>>>> >>>>> >>>>> On Mon, May 13, 2013 at 9:31 AM, Koichi Suzuki < >>>>> koi...@gm...> wrote: >>>>> >>>>>> Hello; >>>>>> >>>>>> I'm testing pgxc_ctl to remove a coordinator master. Following your >>>>>> suggestions, I first stopped the coordinator master to be removed and then >>>>>> issued "drop node" in all the other coordinators. Somehow drop node >>>>>> complains that it fails to obtain pooled connection, in fact, in drop node, >>>>>> "execute direct on (node_to_be_removed)" was issued. >>>>>> >>>>>> It worked fine if the removed coordinator is stopped after all the >>>>>> DROP NODE are successful. >>>>>> >>>>>> Did you issue CLEAN CONNECTION or pgxc_pool_reload before you issue >>>>>> "DROP NODE"? >>>>>> >>>>> >>>>> No, I did not issue any such statement. I just tested again and I am >>>>> also getting the following error when I issue DROP NODE >>>>> test=# drop node coord_2; >>>>> ERROR: Failed to get pooled connections >>>>> CONTEXT: SQL statement "EXECUTE DIRECT ON (coord_2) 'SELECT >>>>> pg_catalog.pg_try_advisory_xact_lock_shared(65535, 0)'" >>>>> test=# >>>>> >>>>> This is a bug and has to be fixed. The bug is that DROP NODE should >>>>> not be trying to acquire the lock. I will send a fix for this today. The >>>>> steps remain the same as before. >>>>> >>>>> >>>>> >>>>>> >>>>>> Regards; >>>>>> ---------- >>>>>> Koichi Suzuki >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> -- >>>>> *Abbas* >>>>> Architect >>>>> >>>>> Ph: 92.334.5100153 >>>>> Skype ID: gabbasb >>>>> www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/> >>>>> * >>>>> Follow us on Twitter* >>>>> @EnterpriseDB >>>>> >>>>> Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Learn Graph Databases - Download FREE O'Reilly Book >>>>> "Graph Databases" is the definitive new guide to graph databases and >>>>> their applications. This 200-page book is written by three acclaimed >>>>> leaders in the field. The early access version is available now. >>>>> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may >>>>> _______________________________________________ >>>>> Postgres-xc-developers mailing list >>>>> Pos...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best Wishes, >>>> Ashutosh Bapat >>>> EntepriseDB Corporation >>>> The Postgres Database Company >>>> >>> >>> >>> >>> -- >>> -- >>> *Abbas* >>> Architect >>> >>> Ph: 92.334.5100153 >>> Skype ID: gabbasb >>> www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/> >>> * >>> Follow us on Twitter* >>> @EnterpriseDB >>> >>> Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community> >>> >>> >>> ------------------------------------------------------------------------------ >>> Learn Graph Databases - Download FREE O'Reilly Book >>> "Graph Databases" is the definitive new guide to graph databases and >>> their applications. This 200-page book is written by three acclaimed >>> leaders in the field. The early access version is available now. >>> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may >>> _______________________________________________ >>> Postgres-xc-developers mailing list >>> Pos...@li... >>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers >>> >>> >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and >> their applications. This 200-page book is written by three acclaimed >> leaders in the field. The early access version is available now. >> Download your free book today! >> http://p.sf.net/sfu/neotech_d2d_may_______________________________________________ >> Postgres-xc-developers mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers >> >> >> >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and >> their applications. This 200-page book is written by three acclaimed >> leaders in the field. The early access version is available now. >> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may >> _______________________________________________ >> Postgres-xc-developers mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers >> >> > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > -- -- *Abbas* Architect Ph: 92.334.5100153 Skype ID: gabbasb www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/> * Follow us on Twitter* @EnterpriseDB Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community> |
From: Koichi S. <koi...@gm...> - 2013-05-13 10:19:28
|
Hello; I found the patch by Abbas was committed. Amit, how does it conflict with your requirement? Do you have any idea how to resolve this? I'm not sure if not using execute direct solves this conflicting requirement. Regards; ---------- Koichi Suzuki 2013/5/13 鈴木 幸市 <ko...@in...> > I'm okay with either case. I can stop the master until all the > coordinator issues DROP NODE and then if the following feature is > available, I can exchange the order (of course, stopping the master first > is safer and more flexible). > > Could somebody check if Michael's patch is available? > > Regards; > --- > Koichi Suzuki > > > > On 2013/05/13, at 17:28, Amit Khandekar <ami...@en...> > wrote: > > > > On 13 May 2013 11:52, Abbas Butt <abb...@en...> wrote: > >> >> >> On Mon, May 13, 2013 at 10:52 AM, Ashutosh Bapat < >> ash...@en...> wrote: >> >>> Hi Abbas, >>> Why is DROP NODE executing EXEC DIRECT ON? The internal code shouldn't >>> do this. EXEC DIRECT is only for debug purposes and can be deprecated in >>> future. In fact, I am leaning to remove it. It's complicating matters a lot. >>> >> >> DROP NODE does not issue EXECUTE DIRECT, it tries to acquire an advisory >> lock and our implementation of advisory lock uses EXEC DIRECT. Please take >> a look at the function pgxc_advisory_lock. Amit can explain it more. >> > > In order to send pg_advisory_lock() in serial manner, one each of the node > one after the other, I had to do this. I guess Michael has now written some > helper functions to execute commands on particular node, which we can use > instead of exec_direct. > > >> >> >>> >>> >>> On Mon, May 13, 2013 at 11:03 AM, Abbas Butt < >>> abb...@en...> wrote: >>> >>>> >>>> >>>> On Mon, May 13, 2013 at 9:31 AM, Koichi Suzuki < >>>> koi...@gm...> wrote: >>>> >>>>> Hello; >>>>> >>>>> I'm testing pgxc_ctl to remove a coordinator master. Following your >>>>> suggestions, I first stopped the coordinator master to be removed and then >>>>> issued "drop node" in all the other coordinators. Somehow drop node >>>>> complains that it fails to obtain pooled connection, in fact, in drop node, >>>>> "execute direct on (node_to_be_removed)" was issued. >>>>> >>>>> It worked fine if the removed coordinator is stopped after all the >>>>> DROP NODE are successful. >>>>> >>>>> Did you issue CLEAN CONNECTION or pgxc_pool_reload before you issue >>>>> "DROP NODE"? >>>>> >>>> >>>> No, I did not issue any such statement. I just tested again and I am >>>> also getting the following error when I issue DROP NODE >>>> test=# drop node coord_2; >>>> ERROR: Failed to get pooled connections >>>> CONTEXT: SQL statement "EXECUTE DIRECT ON (coord_2) 'SELECT >>>> pg_catalog.pg_try_advisory_xact_lock_shared(65535, 0)'" >>>> test=# >>>> >>>> This is a bug and has to be fixed. The bug is that DROP NODE should not >>>> be trying to acquire the lock. I will send a fix for this today. The steps >>>> remain the same as before. >>>> >>>> >>>> >>>>> >>>>> Regards; >>>>> ---------- >>>>> Koichi Suzuki >>>>> >>>> >>>> >>>> >>>> -- >>>> -- >>>> *Abbas* >>>> Architect >>>> >>>> Ph: 92.334.5100153 >>>> Skype ID: gabbasb >>>> www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/> >>>> * >>>> Follow us on Twitter* >>>> @EnterpriseDB >>>> >>>> Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Learn Graph Databases - Download FREE O'Reilly Book >>>> "Graph Databases" is the definitive new guide to graph databases and >>>> their applications. This 200-page book is written by three acclaimed >>>> leaders in the field. The early access version is available now. >>>> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may >>>> _______________________________________________ >>>> Postgres-xc-developers mailing list >>>> Pos...@li... >>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers >>>> >>>> >>> >>> >>> -- >>> Best Wishes, >>> Ashutosh Bapat >>> EntepriseDB Corporation >>> The Postgres Database Company >>> >> >> >> >> -- >> -- >> *Abbas* >> Architect >> >> Ph: 92.334.5100153 >> Skype ID: gabbasb >> www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/> >> * >> Follow us on Twitter* >> @EnterpriseDB >> >> Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community> >> >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and >> their applications. This 200-page book is written by three acclaimed >> leaders in the field. The early access version is available now. >> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may >> _______________________________________________ >> Postgres-xc-developers mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers >> >> > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! > http://p.sf.net/sfu/neotech_d2d_may_______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > |
From: 鈴木 幸市 <ko...@in...> - 2013-05-13 09:58:48
|
I'm okay with either case. I can stop the master until all the coordinator issues DROP NODE and then if the following feature is available, I can exchange the order (of course, stopping the master first is safer and more flexible). Could somebody check if Michael's patch is available? Regards; --- Koichi Suzuki On 2013/05/13, at 17:28, Amit Khandekar <ami...@en...> wrote: > > > On 13 May 2013 11:52, Abbas Butt <abb...@en...> wrote: > > > On Mon, May 13, 2013 at 10:52 AM, Ashutosh Bapat <ash...@en...> wrote: > Hi Abbas, > Why is DROP NODE executing EXEC DIRECT ON? The internal code shouldn't do this. EXEC DIRECT is only for debug purposes and can be deprecated in future. In fact, I am leaning to remove it. It's complicating matters a lot. > > DROP NODE does not issue EXECUTE DIRECT, it tries to acquire an advisory lock and our implementation of advisory lock uses EXEC DIRECT. Please take a look at the function pgxc_advisory_lock. Amit can explain it more. > > In order to send pg_advisory_lock() in serial manner, one each of the node one after the other, I had to do this. I guess Michael has now written some helper functions to execute commands on particular node, which we can use instead of exec_direct. > > > > > On Mon, May 13, 2013 at 11:03 AM, Abbas Butt <abb...@en...> wrote: > > > On Mon, May 13, 2013 at 9:31 AM, Koichi Suzuki <koi...@gm...> wrote: > Hello; > > I'm testing pgxc_ctl to remove a coordinator master. Following your suggestions, I first stopped the coordinator master to be removed and then issued "drop node" in all the other coordinators. Somehow drop node complains that it fails to obtain pooled connection, in fact, in drop node, "execute direct on (node_to_be_removed)" was issued. > > It worked fine if the removed coordinator is stopped after all the DROP NODE are successful. > > Did you issue CLEAN CONNECTION or pgxc_pool_reload before you issue "DROP NODE"? > > No, I did not issue any such statement. I just tested again and I am also getting the following error when I issue DROP NODE > test=# drop node coord_2; > ERROR: Failed to get pooled connections > CONTEXT: SQL statement "EXECUTE DIRECT ON (coord_2) 'SELECT pg_catalog.pg_try_advisory_xact_lock_shared(65535, 0)'" > test=# > > This is a bug and has to be fixed. The bug is that DROP NODE should not be trying to acquire the lock. I will send a fix for this today. The steps remain the same as before. > > > > Regards; > ---------- > Koichi Suzuki > > > > -- > -- > Abbas > Architect > > Ph: 92.334.5100153 > Skype ID: gabbasb > www.enterprisedb.com > > Follow us on Twitter > @EnterpriseDB > > Visit EnterpriseDB for tutorials, webinars, whitepapers and more > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Postgres Database Company > > > > -- > -- > Abbas > Architect > > Ph: 92.334.5100153 > Skype ID: gabbasb > www.enterprisedb.com > > Follow us on Twitter > @EnterpriseDB > > Visit EnterpriseDB for tutorials, webinars, whitepapers and more > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may_______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers |
From: Ashutosh B. <ash...@en...> - 2013-05-13 09:07:02
|
Hi Amit, We now have Query structure in RemoteQuery. This corresponds to the query being fired on the datanodes. THe commandType here should tell you whether it's DELETE or not. On Mon, May 13, 2013 at 1:14 PM, Amit Khandekar < ami...@en...> wrote: > In case of multiple triggers of the same type for a given table, the > requirement is that they should be fired in alphabetical order. To do so, > we need to fire either all of them on coordinator, or all of them on > datanode. The main changes in the attached patch are related to this > requirement. > > All of the Exec*Trigger() functions now execute should_exec_trigger*() > functions that return true if the node on which they are run is the right > node to execute those type of triggers. > > Also for BR triggers, the additional requirement is that they should be > run on coordinator if AR triggers are not shippable, regardless of whether > BR themselves are shippable or not. This is because, if we fire BR triggers > on datanode, they might change the final row updated, and so we need to > again fetch the new row back to the coordinator. Instead, if we fire them > on coordinator, we already know what's the final row. Also, we would have > required additional changes to add RETURNING to the remote query to fetch > the final updated row. > > Constraint triggers are exception; we need to fire them always on > datanode. Once we support global constraints, these need not be specially > handled. > > I was trying to avoid the should_exec_trigger*() calls for each of the > Exec*Trigger() functions by doing this in TriggerEnabled() because it is a > common function called for all triggers. But the issue is, for AFTER > triggers, it is called with a different set of event type values than the > usual TRIGGER_TYPE* values. For AFTER triggers, TRIGGER_EVENT_* values are > used. Anyways, TriggerEnabled() is called for each of the trigger. > > The trigger shippability helper functions are now completely changed. > pgxc_find_nonshippable_row_trig() is the key function. The comments in > these functions should give a fair idea of their functionality. > > > For stmt shippability, the trigger functions are now explicitly called if > it's not an internally generated query. rq_internal_params field is used to > know that this DML is user-supplied query (that is, it would be FQS). The > functions are called in RemoteQueryNext(). > > > THere is another patch (relaccess_type.patch) that you need to first apply > before the main patch (trig_shippability.patch) is applied. I had to add > another RELATION_ACCESS_DELETE in ExecNodes. To handle the stmt triggers, I > had to know whether the statement is DELETE or INSERT or UPDATE. > > The new test xc_trigship is added. > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Postgres Database Company |
From: Amit K. <ami...@en...> - 2013-05-13 08:28:56
|
On 13 May 2013 11:52, Abbas Butt <abb...@en...> wrote: > > > On Mon, May 13, 2013 at 10:52 AM, Ashutosh Bapat < > ash...@en...> wrote: > >> Hi Abbas, >> Why is DROP NODE executing EXEC DIRECT ON? The internal code shouldn't do >> this. EXEC DIRECT is only for debug purposes and can be deprecated in >> future. In fact, I am leaning to remove it. It's complicating matters a lot. >> > > DROP NODE does not issue EXECUTE DIRECT, it tries to acquire an advisory > lock and our implementation of advisory lock uses EXEC DIRECT. Please take > a look at the function pgxc_advisory_lock. Amit can explain it more. > In order to send pg_advisory_lock() in serial manner, one each of the node one after the other, I had to do this. I guess Michael has now written some helper functions to execute commands on particular node, which we can use instead of exec_direct. > > >> >> >> On Mon, May 13, 2013 at 11:03 AM, Abbas Butt <abb...@en... >> > wrote: >> >>> >>> >>> On Mon, May 13, 2013 at 9:31 AM, Koichi Suzuki < >>> koi...@gm...> wrote: >>> >>>> Hello; >>>> >>>> I'm testing pgxc_ctl to remove a coordinator master. Following your >>>> suggestions, I first stopped the coordinator master to be removed and then >>>> issued "drop node" in all the other coordinators. Somehow drop node >>>> complains that it fails to obtain pooled connection, in fact, in drop node, >>>> "execute direct on (node_to_be_removed)" was issued. >>>> >>>> It worked fine if the removed coordinator is stopped after all the DROP >>>> NODE are successful. >>>> >>>> Did you issue CLEAN CONNECTION or pgxc_pool_reload before you issue >>>> "DROP NODE"? >>>> >>> >>> No, I did not issue any such statement. I just tested again and I am >>> also getting the following error when I issue DROP NODE >>> test=# drop node coord_2; >>> ERROR: Failed to get pooled connections >>> CONTEXT: SQL statement "EXECUTE DIRECT ON (coord_2) 'SELECT >>> pg_catalog.pg_try_advisory_xact_lock_shared(65535, 0)'" >>> test=# >>> >>> This is a bug and has to be fixed. The bug is that DROP NODE should not >>> be trying to acquire the lock. I will send a fix for this today. The steps >>> remain the same as before. >>> >>> >>> >>>> >>>> Regards; >>>> ---------- >>>> Koichi Suzuki >>>> >>> >>> >>> >>> -- >>> -- >>> *Abbas* >>> Architect >>> >>> Ph: 92.334.5100153 >>> Skype ID: gabbasb >>> www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/> >>> * >>> Follow us on Twitter* >>> @EnterpriseDB >>> >>> Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community> >>> >>> >>> ------------------------------------------------------------------------------ >>> Learn Graph Databases - Download FREE O'Reilly Book >>> "Graph Databases" is the definitive new guide to graph databases and >>> their applications. This 200-page book is written by three acclaimed >>> leaders in the field. The early access version is available now. >>> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may >>> _______________________________________________ >>> Postgres-xc-developers mailing list >>> Pos...@li... >>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers >>> >>> >> >> >> -- >> Best Wishes, >> Ashutosh Bapat >> EntepriseDB Corporation >> The Postgres Database Company >> > > > > -- > -- > *Abbas* > Architect > > Ph: 92.334.5100153 > Skype ID: gabbasb > www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/> > * > Follow us on Twitter* > @EnterpriseDB > > Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community> > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > |
From: Koichi S. <koi...@gm...> - 2013-05-13 07:52:38
|
Regression test looks okay. Could you commit the patch so that I can continue pgxc_ctl test? Regards; ---------- Koichi Suzuki 2013/5/13 Koichi Suzuki <koi...@gm...> > Hi, > > I tested the patch and found it works fine. Now I can stop the master > first to remove and then issue DROP NODE both for coordinator and > datanode. It is much safer. > > Thank you. > > ---------- > Koichi Suzuki > > > 2013/5/13 Koichi Suzuki <koi...@gm...> > >> Hello; >> >> I'm testing pgxc_ctl to remove a coordinator master. Following your >> suggestions, I first stopped the coordinator master to be removed and then >> issued "drop node" in all the other coordinators. Somehow drop node >> complains that it fails to obtain pooled connection, in fact, in drop node, >> "execute direct on (node_to_be_removed)" was issued. >> >> It worked fine if the removed coordinator is stopped after all the DROP >> NODE are successful. >> >> Did you issue CLEAN CONNECTION or pgxc_pool_reload before you issue "DROP >> NODE"? >> >> Regards; >> ---------- >> Koichi Suzuki >> > > |
From: Koichi S. <koi...@gm...> - 2013-05-13 07:20:28
|
Hi, I tested the patch and found it works fine. Now I can stop the master first to remove and then issue DROP NODE both for coordinator and datanode. It is much safer. Thank you. ---------- Koichi Suzuki 2013/5/13 Koichi Suzuki <koi...@gm...> > Hello; > > I'm testing pgxc_ctl to remove a coordinator master. Following your > suggestions, I first stopped the coordinator master to be removed and then > issued "drop node" in all the other coordinators. Somehow drop node > complains that it fails to obtain pooled connection, in fact, in drop node, > "execute direct on (node_to_be_removed)" was issued. > > It worked fine if the removed coordinator is stopped after all the DROP > NODE are successful. > > Did you issue CLEAN CONNECTION or pgxc_pool_reload before you issue "DROP > NODE"? > > Regards; > ---------- > Koichi Suzuki > |
From: 鈴木 幸市 <ko...@in...> - 2013-05-13 07:01:01
|
Thanks. I will try it and let you know if it works fine. Regards; --- Koichi Suzuki On 2013/05/13, at 15:23, Abbas Butt <abb...@en...> wrote: > PFA patch to fix this issue. If you find that it works for you I can commit it later today. Thanks. > > On Mon, May 13, 2013 at 10:33 AM, Abbas Butt <abb...@en...> wrote: > > > On Mon, May 13, 2013 at 9:31 AM, Koichi Suzuki <koi...@gm...> wrote: > Hello; > > I'm testing pgxc_ctl to remove a coordinator master. Following your suggestions, I first stopped the coordinator master to be removed and then issued "drop node" in all the other coordinators. Somehow drop node complains that it fails to obtain pooled connection, in fact, in drop node, "execute direct on (node_to_be_removed)" was issued. > > It worked fine if the removed coordinator is stopped after all the DROP NODE are successful. > > Did you issue CLEAN CONNECTION or pgxc_pool_reload before you issue "DROP NODE"? > > No, I did not issue any such statement. I just tested again and I am also getting the following error when I issue DROP NODE > test=# drop node coord_2; > ERROR: Failed to get pooled connections > CONTEXT: SQL statement "EXECUTE DIRECT ON (coord_2) 'SELECT pg_catalog.pg_try_advisory_xact_lock_shared(65535, 0)'" > test=# > > This is a bug and has to be fixed. The bug is that DROP NODE should not be trying to acquire the lock. I will send a fix for this today. The steps remain the same as before. > > > > Regards; > ---------- > Koichi Suzuki > > > > -- > -- > Abbas > Architect > > Ph: 92.334.5100153 > Skype ID: gabbasb > www.enterprisedb.com > > Follow us on Twitter > @EnterpriseDB > > Visit EnterpriseDB for tutorials, webinars, whitepapers and more > > > > -- > -- > Abbas > Architect > > Ph: 92.334.5100153 > Skype ID: gabbasb > www.enterprisedb.com > > Follow us on Twitter > @EnterpriseDB > > Visit EnterpriseDB for tutorials, webinars, whitepapers and more > <1_drop_node.patch>------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may_______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers |
From: Abbas B. <abb...@en...> - 2013-05-13 06:23:54
|
PFA patch to fix this issue. If you find that it works for you I can commit it later today. Thanks. On Mon, May 13, 2013 at 10:33 AM, Abbas Butt <abb...@en...>wrote: > > > On Mon, May 13, 2013 at 9:31 AM, Koichi Suzuki <koi...@gm...>wrote: > >> Hello; >> >> I'm testing pgxc_ctl to remove a coordinator master. Following your >> suggestions, I first stopped the coordinator master to be removed and then >> issued "drop node" in all the other coordinators. Somehow drop node >> complains that it fails to obtain pooled connection, in fact, in drop node, >> "execute direct on (node_to_be_removed)" was issued. >> >> It worked fine if the removed coordinator is stopped after all the DROP >> NODE are successful. >> >> Did you issue CLEAN CONNECTION or pgxc_pool_reload before you issue "DROP >> NODE"? >> > > No, I did not issue any such statement. I just tested again and I am also > getting the following error when I issue DROP NODE > test=# drop node coord_2; > ERROR: Failed to get pooled connections > CONTEXT: SQL statement "EXECUTE DIRECT ON (coord_2) 'SELECT > pg_catalog.pg_try_advisory_xact_lock_shared(65535, 0)'" > test=# > > This is a bug and has to be fixed. The bug is that DROP NODE should not be > trying to acquire the lock. I will send a fix for this today. The steps > remain the same as before. > > > >> >> Regards; >> ---------- >> Koichi Suzuki >> > > > > -- > -- > *Abbas* > Architect > > Ph: 92.334.5100153 > Skype ID: gabbasb > www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/> > * > Follow us on Twitter* > @EnterpriseDB > > Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community> > -- -- *Abbas* Architect Ph: 92.334.5100153 Skype ID: gabbasb www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/> * Follow us on Twitter* @EnterpriseDB Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community> |
From: Abbas B. <abb...@en...> - 2013-05-13 06:22:09
|
On Mon, May 13, 2013 at 10:52 AM, Ashutosh Bapat < ash...@en...> wrote: > Hi Abbas, > Why is DROP NODE executing EXEC DIRECT ON? The internal code shouldn't do > this. EXEC DIRECT is only for debug purposes and can be deprecated in > future. In fact, I am leaning to remove it. It's complicating matters a lot. > DROP NODE does not issue EXECUTE DIRECT, it tries to acquire an advisory lock and our implementation of advisory lock uses EXEC DIRECT. Please take a look at the function pgxc_advisory_lock. Amit can explain it more. > > > On Mon, May 13, 2013 at 11:03 AM, Abbas Butt <abb...@en...>wrote: > >> >> >> On Mon, May 13, 2013 at 9:31 AM, Koichi Suzuki <koi...@gm... >> > wrote: >> >>> Hello; >>> >>> I'm testing pgxc_ctl to remove a coordinator master. Following your >>> suggestions, I first stopped the coordinator master to be removed and then >>> issued "drop node" in all the other coordinators. Somehow drop node >>> complains that it fails to obtain pooled connection, in fact, in drop node, >>> "execute direct on (node_to_be_removed)" was issued. >>> >>> It worked fine if the removed coordinator is stopped after all the DROP >>> NODE are successful. >>> >>> Did you issue CLEAN CONNECTION or pgxc_pool_reload before you issue >>> "DROP NODE"? >>> >> >> No, I did not issue any such statement. I just tested again and I am also >> getting the following error when I issue DROP NODE >> test=# drop node coord_2; >> ERROR: Failed to get pooled connections >> CONTEXT: SQL statement "EXECUTE DIRECT ON (coord_2) 'SELECT >> pg_catalog.pg_try_advisory_xact_lock_shared(65535, 0)'" >> test=# >> >> This is a bug and has to be fixed. The bug is that DROP NODE should not >> be trying to acquire the lock. I will send a fix for this today. The steps >> remain the same as before. >> >> >> >>> >>> Regards; >>> ---------- >>> Koichi Suzuki >>> >> >> >> >> -- >> -- >> *Abbas* >> Architect >> >> Ph: 92.334.5100153 >> Skype ID: gabbasb >> www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/> >> * >> Follow us on Twitter* >> @EnterpriseDB >> >> Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community> >> >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and >> their applications. This 200-page book is written by three acclaimed >> leaders in the field. The early access version is available now. >> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may >> _______________________________________________ >> Postgres-xc-developers mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers >> >> > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Postgres Database Company > -- -- *Abbas* Architect Ph: 92.334.5100153 Skype ID: gabbasb www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/> * Follow us on Twitter* @EnterpriseDB Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community> |
From: Ashutosh B. <ash...@en...> - 2013-05-13 05:52:26
|
Hi Abbas, Why is DROP NODE executing EXEC DIRECT ON? The internal code shouldn't do this. EXEC DIRECT is only for debug purposes and can be deprecated in future. In fact, I am leaning to remove it. It's complicating matters a lot. On Mon, May 13, 2013 at 11:03 AM, Abbas Butt <abb...@en...>wrote: > > > On Mon, May 13, 2013 at 9:31 AM, Koichi Suzuki <koi...@gm...>wrote: > >> Hello; >> >> I'm testing pgxc_ctl to remove a coordinator master. Following your >> suggestions, I first stopped the coordinator master to be removed and then >> issued "drop node" in all the other coordinators. Somehow drop node >> complains that it fails to obtain pooled connection, in fact, in drop node, >> "execute direct on (node_to_be_removed)" was issued. >> >> It worked fine if the removed coordinator is stopped after all the DROP >> NODE are successful. >> >> Did you issue CLEAN CONNECTION or pgxc_pool_reload before you issue "DROP >> NODE"? >> > > No, I did not issue any such statement. I just tested again and I am also > getting the following error when I issue DROP NODE > test=# drop node coord_2; > ERROR: Failed to get pooled connections > CONTEXT: SQL statement "EXECUTE DIRECT ON (coord_2) 'SELECT > pg_catalog.pg_try_advisory_xact_lock_shared(65535, 0)'" > test=# > > This is a bug and has to be fixed. The bug is that DROP NODE should not be > trying to acquire the lock. I will send a fix for this today. The steps > remain the same as before. > > > >> >> Regards; >> ---------- >> Koichi Suzuki >> > > > > -- > -- > *Abbas* > Architect > > Ph: 92.334.5100153 > Skype ID: gabbasb > www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/> > * > Follow us on Twitter* > @EnterpriseDB > > Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community> > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Postgres Database Company |
From: Abbas B. <abb...@en...> - 2013-05-13 05:34:10
|
On Mon, May 13, 2013 at 9:31 AM, Koichi Suzuki <koi...@gm...>wrote: > Hello; > > I'm testing pgxc_ctl to remove a coordinator master. Following your > suggestions, I first stopped the coordinator master to be removed and then > issued "drop node" in all the other coordinators. Somehow drop node > complains that it fails to obtain pooled connection, in fact, in drop node, > "execute direct on (node_to_be_removed)" was issued. > > It worked fine if the removed coordinator is stopped after all the DROP > NODE are successful. > > Did you issue CLEAN CONNECTION or pgxc_pool_reload before you issue "DROP > NODE"? > No, I did not issue any such statement. I just tested again and I am also getting the following error when I issue DROP NODE test=# drop node coord_2; ERROR: Failed to get pooled connections CONTEXT: SQL statement "EXECUTE DIRECT ON (coord_2) 'SELECT pg_catalog.pg_try_advisory_xact_lock_shared(65535, 0)'" test=# This is a bug and has to be fixed. The bug is that DROP NODE should not be trying to acquire the lock. I will send a fix for this today. The steps remain the same as before. > > Regards; > ---------- > Koichi Suzuki > -- -- *Abbas* Architect Ph: 92.334.5100153 Skype ID: gabbasb www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/> * Follow us on Twitter* @EnterpriseDB Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community>and more<http://www.enterprisedb.com/resources-community> |
From: Koichi S. <koi...@gm...> - 2013-05-13 04:31:36
|
Hello; I'm testing pgxc_ctl to remove a coordinator master. Following your suggestions, I first stopped the coordinator master to be removed and then issued "drop node" in all the other coordinators. Somehow drop node complains that it fails to obtain pooled connection, in fact, in drop node, "execute direct on (node_to_be_removed)" was issued. It worked fine if the removed coordinator is stopped after all the DROP NODE are successful. Did you issue CLEAN CONNECTION or pgxc_pool_reload before you issue "DROP NODE"? Regards; ---------- Koichi Suzuki |
From: Adam D. <ada...@sm...> - 2013-05-12 16:05:12
|
# ---------------------- # GTM configuration file # ---------------------- # # This file must be placed on gtm working directory # specified by -D command line option of gtm or gtm_ctl. The # configuration file name must be "gtm.conf" # # # This file consists of lines of the form # # name = value # # (The "=" is optional.) Whitespace may be used. Comments are # introduced with "#" anywhere on a line. The complete list of # parameter names and allowed values can be found in the # Postgres-XC documentation. # # The commented-out settings shown in this file represent the default # values. # # Re-commenting a setting is NOT sufficient to revert it to the default # value. # # You need to restart the server. #------------------------------------------------------------------------------ # GENERAL PARAMETERS #------------------------------------------------------------------------------ nodename = 'GTM1' # Specifies the node name. # (changes requires restart) listen_addresses = '*' # Listen addresses of this GTM. # (changes requires restart) port = 20001 # Port number of this GTM. # (changes requires restart) #startup = ACT # Start mode. ACT/STANDBY. #------------------------------------------------------------------------------ # GTM STANDBY PARAMETERS #------------------------------------------------------------------------------ #Those parameters are effective when GTM is activated as a standby server #active_host = '' # Listen address of active GTM. # (changes requires restart) #active_port = # Port number of active GTM. # (changes requires restart) #--------------------------------------- # OTHER OPTIONS #--------------------------------------- #keepalives_idle = 0 # Keepalives_idle parameter. #keepalives_interval = 0 # Keepalives_interval parameter. #keepalives_count = 0 # Keepalives_count internal parameter. #log_file = 'gtm.log' # Log file name #log_min_messages = DEBUG5 # log_min_messages. Default WARNING. # Valid value: DEBUG, DEBUG5, DEBUG4, DEBUG3, # DEBUG2, DEBUG1, INFO, NOTICE, WARNING, # ERROR, LOG, FATAL, PANIC #synchronous_backup = off # If backup to standby is synchronous |
From: Koichi S. <koi...@gm...> - 2013-05-10 15:38:37
|
---------- Koichi Suzuki 2013/5/10 Amit Khandekar <ami...@en...> > > > On 10 May 2013 17:59, Michael Paquier <mic...@gm...> wrote: > >> >> >> >> On Fri, May 10, 2013 at 2:59 PM, Ashutosh Bapat < >> ash...@en...> wrote: >> >>> Can you comment on this, since you are the one who implemented statement >>> triggers? >>> >> About the shippability of triggers, here is some food for brain: >> http://michael.otacoo.com/postgresql-2/triggers-in-a-cluster-database/ >> >> In short, a trigger can be fired on a remote node only if: >> - the query that triggered it is FQSed >> - the fired procedure is immutable. There might be cases where a trigger >> with a stable procedure could be shippable but this would be dangerous... >> There are already some APIs I implemented that you can use if they are >> not used already (trigger.c or something in the shippability APIs of the >> optimizer I don't recall precisely). >> >> Just knowing that 99% of triggers do not use immutable functions is >> enough to shoot all the triggers on Coordinators, you will be bad >> performance for row triggers but if you don't do that data consistency is >> badly endangered. However for correctness you should open the open to >> immutable triggers being shippable. >> > > Actually I don't want to go into general shippability of statements in > trigger context; that is another issue having a bigger scope. My point for > this mail thread is for this specific case: What to do about statement > triggers, whether we should indeed run *statement* triggers on datanode on > the basis that the trigger function is safe to be run on datanode. Here is > the key point I made : > I agree that the general function shippability is another issue to solve. > > "For a non-FQS'ed DML, a DML is executed on datanode for each row to be > processed. So if a user updates 10 rows with a non-shippable query, the > coordinator will execute a parameterized remote update query on datanode > for each of the 10 ctids found using the quals. And if we execute shippable > statement triggers on datanode, the statement trigger will be executed 10 > times on datanode, which is not expected from the user. That's the reason > we should fire statement triggers always on coordinator regardless of > anything" > > Let me know if you have any comments on this specific point. > This is quite reasonable approach, I think. Statement trigger should be fired only once and because only a coordinator is aware of such statements, it is quite natural that statment trigger should be fired on the coordinator. Best; --- Koichi Suzuki > > -- >> Michael >> > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > |