Menu
▾
▴
postgres-xc-developers — Postgres-XC hackers and developers
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
|
|
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 > > |
|
From: Amit K. <ami...@en...> - 2013-05-10 13:01:01
|
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 : "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. -- > Michael > |
|
From: Ashutosh B. <ash...@en...> - 2013-05-10 12:31:25
|
On Fri, May 10, 2013 at 5:59 PM, 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 > That's busted, and hence this whole mail tread. > - 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). > Unfortunately those APIs are found to be heavily erroneous and Amit is currently working on writing correct APIs. > > 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. > -- > Michael > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Postgres Database Company |
|
From: Michael P. <mic...@gm...> - 2013-05-10 12:29:25
|
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. -- Michael |
|
From: Amit K. <ami...@en...> - 2013-05-10 12:10:02
|
On 10 May 2013 16:00, Koichi Suzuki <koi...@gm...> wrote: > I think this is a reasonable point to start with. > However, in general, TRIGGER is an expensive action so I believe we should > provide more sophisiticated optimization of TRIGGER action. I understand > this is not an issue of TRIGGER. We need to look into rewriter, function > shippability (current shippability is safe but not optimal -- I'd like to > discuss this shortly), and statement shippability, I mean partial statment > shippability. > > That's a long standing issue that we have been discussing as to what are the various ways in which a user can make trigger functions execute safely on datanode. Actually the performance impact is particularly critical for row triggers, not so much for statement triggers since they execute only once. I undertand trigger action needs careful and sophisticated design and has > complicated relationship with other component of query processing. > > > Best; > > ---------- > Koichi Suzuki > > > 2013/5/10 Amit Khandekar <ami...@en...> > >> >> >> On 10 May 2013 11:29, Ashutosh Bapat <ash...@en...>wrote: >> >>> >>> Hi Amit, >>> This looks fine from correctness perspective and may be ok for this >>> release. I hope, we can still FQS the query and not ship the triggers. >>> >> >> Yes, that's the idea. We handle statement triggers explicitly on >> coordinator for FQS. We define a resultRelInfo in RemoteQuery if it is FQS, >> and then call the BS and AS triggers in ExecInitRemoteQuery() and >> ExecEndRemoteQuery() if resultRelInfo is set. >> >> >> How would it affect performance? >>> >> >> Since the query would still be FQSed even for non-shippable stmt trigger, >> this does not impact performance. Stmt trigger would be fired only once. >> >> Michael, >> >>> Can you comment on this, since you are the one who implemented statement >>> triggers? >>> >>> >>> On Fri, May 10, 2013 at 10:33 AM, Amit Khandekar < >>> ami...@en...> wrote: >>> >>>> We can consider applying the usual row-trigger rules of trigger >>>> shippability to statement triggers: >>>> If the trigger function is shippable, execute the trigger on datanode, >>>> else on coordinator. >>>> >>>> It is not as trivial as it sounds though. 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. Is >>>> this expected from the user ? >>>> >>>> From the user's perspective, the statement is executed once, so the >>>> statement trigger should be fired only once. Typical use case is that the >>>> user queries need to be logged/audited. So we need to prevent firing >>>> statement triggers on datanode for non-FQS'ed query. But should the user >>>> define the stmt trigger function as immutable in such a case ? May be not >>>> in this auditing scenario. But it is not very clear what would a shippable >>>> statement trigger mean to the user exactly. If the function is really one >>>> which does not access the database as per the immutable definition, then it >>>> anyway does not matter how many times it gets executed on datanode for a >>>> given statement. >>>> >>>> I think the solution is to *always* fire statement triggers on >>>> *coordinator* regardless of shippability or whether it is FQS or non-FQS. >>>> For FQS query, we need to explicitly fire stmt trigger before/after the >>>> fqs'ed query node is executed, may be inside the ExecRemoteQuery() function >>>> itself. >>>> >>>> Comments ? >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> 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 >>> >> >> >> >> ------------------------------------------------------------------------------ >> 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-10 10:30:30
|
I think this is a reasonable point to start with. However, in general, TRIGGER is an expensive action so I believe we should provide more sophisiticated optimization of TRIGGER action. I understand this is not an issue of TRIGGER. We need to look into rewriter, function shippability (current shippability is safe but not optimal -- I'd like to discuss this shortly), and statement shippability, I mean partial statment shippability. I undertand trigger action needs careful and sophisticated design and has complicated relationship with other component of query processing. Best; ---------- Koichi Suzuki 2013/5/10 Amit Khandekar <ami...@en...> > > > On 10 May 2013 11:29, Ashutosh Bapat <ash...@en...>wrote: > >> >> Hi Amit, >> This looks fine from correctness perspective and may be ok for this >> release. I hope, we can still FQS the query and not ship the triggers. >> > > Yes, that's the idea. We handle statement triggers explicitly on > coordinator for FQS. We define a resultRelInfo in RemoteQuery if it is FQS, > and then call the BS and AS triggers in ExecInitRemoteQuery() and > ExecEndRemoteQuery() if resultRelInfo is set. > > > How would it affect performance? >> > > Since the query would still be FQSed even for non-shippable stmt trigger, > this does not impact performance. Stmt trigger would be fired only once. > > Michael, > >> Can you comment on this, since you are the one who implemented statement >> triggers? >> >> >> On Fri, May 10, 2013 at 10:33 AM, Amit Khandekar < >> ami...@en...> wrote: >> >>> We can consider applying the usual row-trigger rules of trigger >>> shippability to statement triggers: >>> If the trigger function is shippable, execute the trigger on datanode, >>> else on coordinator. >>> >>> It is not as trivial as it sounds though. 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. Is >>> this expected from the user ? >>> >>> From the user's perspective, the statement is executed once, so the >>> statement trigger should be fired only once. Typical use case is that the >>> user queries need to be logged/audited. So we need to prevent firing >>> statement triggers on datanode for non-FQS'ed query. But should the user >>> define the stmt trigger function as immutable in such a case ? May be not >>> in this auditing scenario. But it is not very clear what would a shippable >>> statement trigger mean to the user exactly. If the function is really one >>> which does not access the database as per the immutable definition, then it >>> anyway does not matter how many times it gets executed on datanode for a >>> given statement. >>> >>> I think the solution is to *always* fire statement triggers on >>> *coordinator* regardless of shippability or whether it is FQS or non-FQS. >>> For FQS query, we need to explicitly fire stmt trigger before/after the >>> fqs'ed query node is executed, may be inside the ExecRemoteQuery() function >>> itself. >>> >>> Comments ? >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >> > > > > ------------------------------------------------------------------------------ > 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: Amit K. <ami...@en...> - 2013-05-10 06:07:21
|
On 10 May 2013 11:29, Ashutosh Bapat <ash...@en...>wrote: > > Hi Amit, > This looks fine from correctness perspective and may be ok for this > release. I hope, we can still FQS the query and not ship the triggers. > Yes, that's the idea. We handle statement triggers explicitly on coordinator for FQS. We define a resultRelInfo in RemoteQuery if it is FQS, and then call the BS and AS triggers in ExecInitRemoteQuery() and ExecEndRemoteQuery() if resultRelInfo is set. How would it affect performance? > Since the query would still be FQSed even for non-shippable stmt trigger, this does not impact performance. Stmt trigger would be fired only once. Michael, > Can you comment on this, since you are the one who implemented statement > triggers? > > > On Fri, May 10, 2013 at 10:33 AM, Amit Khandekar < > ami...@en...> wrote: > >> We can consider applying the usual row-trigger rules of trigger >> shippability to statement triggers: >> If the trigger function is shippable, execute the trigger on datanode, >> else on coordinator. >> >> It is not as trivial as it sounds though. 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. Is >> this expected from the user ? >> >> From the user's perspective, the statement is executed once, so the >> statement trigger should be fired only once. Typical use case is that the >> user queries need to be logged/audited. So we need to prevent firing >> statement triggers on datanode for non-FQS'ed query. But should the user >> define the stmt trigger function as immutable in such a case ? May be not >> in this auditing scenario. But it is not very clear what would a shippable >> statement trigger mean to the user exactly. If the function is really one >> which does not access the database as per the immutable definition, then it >> anyway does not matter how many times it gets executed on datanode for a >> given statement. >> >> I think the solution is to *always* fire statement triggers on >> *coordinator* regardless of shippability or whether it is FQS or non-FQS. >> For FQS query, we need to explicitly fire stmt trigger before/after the >> fqs'ed query node is executed, may be inside the ExecRemoteQuery() function >> itself. >> >> Comments ? >> >> >> ------------------------------------------------------------------------------ >> 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: Ashutosh B. <ash...@en...> - 2013-05-10 05:59:15
|
Hi Amit, This looks fine from correctness perspective and may be ok for this release. I hope, we can still FQS the query and not ship the triggers. How would it affect performance? Michael, Can you comment on this, since you are the one who implemented statement triggers? On Fri, May 10, 2013 at 10:33 AM, Amit Khandekar < ami...@en...> wrote: > We can consider applying the usual row-trigger rules of trigger > shippability to statement triggers: > If the trigger function is shippable, execute the trigger on datanode, > else on coordinator. > > It is not as trivial as it sounds though. 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. Is > this expected from the user ? > > From the user's perspective, the statement is executed once, so the > statement trigger should be fired only once. Typical use case is that the > user queries need to be logged/audited. So we need to prevent firing > statement triggers on datanode for non-FQS'ed query. But should the user > define the stmt trigger function as immutable in such a case ? May be not > in this auditing scenario. But it is not very clear what would a shippable > statement trigger mean to the user exactly. If the function is really one > which does not access the database as per the immutable definition, then it > anyway does not matter how many times it gets executed on datanode for a > given statement. > > I think the solution is to *always* fire statement triggers on > *coordinator* regardless of shippability or whether it is FQS or non-FQS. > For FQS query, we need to explicitly fire stmt trigger before/after the > fqs'ed query node is executed, may be inside the ExecRemoteQuery() function > itself. > > Comments ? > > > ------------------------------------------------------------------------------ > 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-10 05:04:22
|
We can consider applying the usual row-trigger rules of trigger shippability to statement triggers: If the trigger function is shippable, execute the trigger on datanode, else on coordinator. It is not as trivial as it sounds though. 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. Is this expected from the user ? >From the user's perspective, the statement is executed once, so the statement trigger should be fired only once. Typical use case is that the user queries need to be logged/audited. So we need to prevent firing statement triggers on datanode for non-FQS'ed query. But should the user define the stmt trigger function as immutable in such a case ? May be not in this auditing scenario. But it is not very clear what would a shippable statement trigger mean to the user exactly. If the function is really one which does not access the database as per the immutable definition, then it anyway does not matter how many times it gets executed on datanode for a given statement. I think the solution is to *always* fire statement triggers on *coordinator* regardless of shippability or whether it is FQS or non-FQS. For FQS query, we need to explicitly fire stmt trigger before/after the fqs'ed query node is executed, may be inside the ExecRemoteQuery() function itself. Comments ? |
|
From: Koichi S. <koi...@gm...> - 2013-05-09 14:32:03
|
Because such case will end up with an error, I'm afraid the additional code may not work much. Regards; ---------- Koichi Suzuki 2013/5/9 Nikhil Sontakke <ni...@st...> > > > Hmmm... This is not a simple issue to fix. Maybe we should document that >> the access privilege to the view must be the same as those of the base >> tables. >> >> Any other inputs to this? >> >> > Or in XC, we should add code to check that the grants to the view should > also be the same as underlying referenced tables. > > Regards, > Nikhils > > > >> ---------- >> Koichi Suzuki >> >> >> 2013/5/9 Abbas Butt <abb...@en...> >> >>> Consider this test cases, which has been taken form select_views.sql >>> and simplified to pin point the issue. >>> >>> CREATE ROLE regress_alice; >>> CREATE TABLE customer(cid int primary key, name text not null, tel text, >>> passwd text); >>> >>> INSERT INTO customer VALUES >>> (101, 'regress_alice', '+81-12-3456-7890', 'passwd123'), >>> (102, 'regress_bob', '+01-234-567-8901', 'beafsteak'); >>> >>> CREATE VIEW my_property_normal AS SELECT * FROM customer; >>> >>> GRANT SELECT ON my_property_normal TO public; >>> >>> SET SESSION AUTHORIZATION regress_alice; >>> >>> >>> On PG >>> ===== >>> >>> test=> EXPLAIN VERBOSE SELECT * FROM my_property_normal; >>> QUERY PLAN >>> ---------------------------------------------------------------------- >>> Seq Scan on public.customer (cost=0.00..16.20 rows=620 width=100) >>> Output: customer.cid, customer.name, customer.tel, customer.passwd >>> (2 rows) >>> >>> test=> >>> test=> SELECT * FROM my_property_normal; >>> cid | name | tel | passwd >>> -----+---------------+------------------+----------- >>> 101 | regress_alice | +81-12-3456-7890 | passwd123 >>> 102 | regress_bob | +01-234-567-8901 | beafsteak >>> (2 rows) >>> >>> On XC >>> ===== >>> >>> test=> EXPLAIN VERBOSE SELECT * FROM my_property_normal; >>> QUERY PLAN >>> >>> --------------------------------------------------------------------------------------------------------------------- >>> Data Node Scan on "__REMOTE_FQS_QUERY__" (cost=0.00..0.00 rows=0 >>> width=0) >>> Output: my_property_normal.cid, my_property_normal.name, >>> my_property_normal.tel, my_property_normal.passwd >>> Node/s: data_node_1, data_node_2, data_node_3, data_node_4 >>> Remote query: SELECT cid, name, tel, passwd FROM (SELECT >>> customer.cid, customer.name, customer.tel, customer.passwd FROM >>> customer) my_property_normal >>> (4 rows) >>> >>> test=> >>> test=> SELECT * FROM my_property_normal; >>> ERROR: permission denied for relation customer >>> >>> Please refer to the documentation at >>> http://www.postgresql.org/docs/9.2/static/rules-privileges.html >>> It says >>> "*Relations that are used due to rules get checked against the >>> privileges of the rule owner, not the user invoking the rule. This means >>> that a user only needs the required privileges for the tables/views that he >>> names explicitly in his queries.*" >>> >>> It is because of this fact that the query >>> SELECT * FROM my_property_normal >>> works fine when issued on PG. >>> In XC on the other hand, since views are not even created on datanodes, >>> they (datanodes) are not even aware that the query is actually a select >>> form a view, let alone enforcing the above statement in documentation. >>> >>> What strategy are we going to fix this problem? >>> Are we going to fix it or do some changes in documentation? >>> Regards >>> Abbas >>> >>> >>> >>> On Tue, May 7, 2013 at 11:38 AM, Abbas Butt <abb...@en... >>> > wrote: >>> >>>> ok, sure. >>>> >>>> >>>> On Tue, May 7, 2013 at 11:37 AM, Ashutosh Bapat < >>>> ash...@en...> wrote: >>>> >>>>> BTW, fix the bug in separate patch and fix expected outputs in >>>>> separate patch. >>>>> >>>>> >>>>> On Tue, May 7, 2013 at 11:54 AM, Ashutosh Bapat < >>>>> ash...@en...> wrote: >>>>> >>>>>> Can you please fix the bug then? >>>>>> >>>>>> >>>>>> On Tue, May 7, 2013 at 10:25 AM, Abbas Butt < >>>>>> abb...@en...> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Apr 30, 2013 at 4:57 PM, Ashutosh Bapat < >>>>>>> ash...@en...> wrote: >>>>>>> >>>>>>>> Hi Abbas, >>>>>>>> I see that the EXPLAIN commands are changed to include the XC >>>>>>>> specific options. Since the original test is using capital letters >>>>>>>> everywhere, it's better to maintain that style. >>>>>>>> >>>>>>> >>>>>>> Done. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Please make sure that the changes you have done (explain output) >>>>>>>> reflect in all the alt. expected output files. >>>>>>>> >>>>>>> >>>>>>> Done. >>>>>>> >>>>>>> >>>>>>>> Can you please see if we can eliminate the alternate expected >>>>>>>> output files as well? What are the reasons we have to maintain those? >>>>>>>> >>>>>>> >>>>>>> select_views.out and select_view_1.out are maintained by vanilla PG. >>>>>>> We have added select_views_2.out and It can be removed, however I noticed >>>>>>> that the test case that was added (Leaky View Scenario) is failing and >>>>>>> needs a fix. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Apr 24, 2013 at 10:59 PM, Abbas Butt < >>>>>>>> abb...@en...> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> The test was failing because some more tests are added in sql file. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *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> >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>> Try New Relic Now & We'll Send You this Cool Shirt >>>>>>>>> New Relic is the only SaaS-based application performance >>>>>>>>> monitoring service >>>>>>>>> that delivers powerful full stack analytics. Optimize and monitor >>>>>>>>> your >>>>>>>>> browser, app, & servers with just a few lines of code. Try New >>>>>>>>> Relic >>>>>>>>> and get this awesome Nerd Life shirt! >>>>>>>>> http://p.sf.net/sfu/newrelic_d2d_apr >>>>>>>>> _______________________________________________ >>>>>>>>> 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> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best Wishes, >>>>>> Ashutosh Bapat >>>>>> EntepriseDB Corporation >>>>>> The Postgres Database Company >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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> >>>> >>> >>> >>> >>> -- >>> -- >>> *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 >> >> > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > |
|
From: Nikhil S. <ni...@st...> - 2013-05-09 14:08:09
|
Hmmm... This is not a simple issue to fix. Maybe we should document that > the access privilege to the view must be the same as those of the base > tables. > > Any other inputs to this? > > Or in XC, we should add code to check that the grants to the view should also be the same as underlying referenced tables. Regards, Nikhils > ---------- > Koichi Suzuki > > > 2013/5/9 Abbas Butt <abb...@en...> > >> Consider this test cases, which has been taken form select_views.sql and >> simplified to pin point the issue. >> >> CREATE ROLE regress_alice; >> CREATE TABLE customer(cid int primary key, name text not null, tel text, >> passwd text); >> >> INSERT INTO customer VALUES >> (101, 'regress_alice', '+81-12-3456-7890', 'passwd123'), >> (102, 'regress_bob', '+01-234-567-8901', 'beafsteak'); >> >> CREATE VIEW my_property_normal AS SELECT * FROM customer; >> >> GRANT SELECT ON my_property_normal TO public; >> >> SET SESSION AUTHORIZATION regress_alice; >> >> >> On PG >> ===== >> >> test=> EXPLAIN VERBOSE SELECT * FROM my_property_normal; >> QUERY PLAN >> ---------------------------------------------------------------------- >> Seq Scan on public.customer (cost=0.00..16.20 rows=620 width=100) >> Output: customer.cid, customer.name, customer.tel, customer.passwd >> (2 rows) >> >> test=> >> test=> SELECT * FROM my_property_normal; >> cid | name | tel | passwd >> -----+---------------+------------------+----------- >> 101 | regress_alice | +81-12-3456-7890 | passwd123 >> 102 | regress_bob | +01-234-567-8901 | beafsteak >> (2 rows) >> >> On XC >> ===== >> >> test=> EXPLAIN VERBOSE SELECT * FROM my_property_normal; >> QUERY PLAN >> >> --------------------------------------------------------------------------------------------------------------------- >> Data Node Scan on "__REMOTE_FQS_QUERY__" (cost=0.00..0.00 rows=0 >> width=0) >> Output: my_property_normal.cid, my_property_normal.name, >> my_property_normal.tel, my_property_normal.passwd >> Node/s: data_node_1, data_node_2, data_node_3, data_node_4 >> Remote query: SELECT cid, name, tel, passwd FROM (SELECT customer.cid, >> customer.name, customer.tel, customer.passwd FROM customer) >> my_property_normal >> (4 rows) >> >> test=> >> test=> SELECT * FROM my_property_normal; >> ERROR: permission denied for relation customer >> >> Please refer to the documentation at >> http://www.postgresql.org/docs/9.2/static/rules-privileges.html >> It says >> "*Relations that are used due to rules get checked against the >> privileges of the rule owner, not the user invoking the rule. This means >> that a user only needs the required privileges for the tables/views that he >> names explicitly in his queries.*" >> >> It is because of this fact that the query >> SELECT * FROM my_property_normal >> works fine when issued on PG. >> In XC on the other hand, since views are not even created on datanodes, >> they (datanodes) are not even aware that the query is actually a select >> form a view, let alone enforcing the above statement in documentation. >> >> What strategy are we going to fix this problem? >> Are we going to fix it or do some changes in documentation? >> Regards >> Abbas >> >> >> >> On Tue, May 7, 2013 at 11:38 AM, Abbas Butt <abb...@en...>wrote: >> >>> ok, sure. >>> >>> >>> On Tue, May 7, 2013 at 11:37 AM, Ashutosh Bapat < >>> ash...@en...> wrote: >>> >>>> BTW, fix the bug in separate patch and fix expected outputs in separate >>>> patch. >>>> >>>> >>>> On Tue, May 7, 2013 at 11:54 AM, Ashutosh Bapat < >>>> ash...@en...> wrote: >>>> >>>>> Can you please fix the bug then? >>>>> >>>>> >>>>> On Tue, May 7, 2013 at 10:25 AM, Abbas Butt < >>>>> abb...@en...> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Apr 30, 2013 at 4:57 PM, Ashutosh Bapat < >>>>>> ash...@en...> wrote: >>>>>> >>>>>>> Hi Abbas, >>>>>>> I see that the EXPLAIN commands are changed to include the XC >>>>>>> specific options. Since the original test is using capital letters >>>>>>> everywhere, it's better to maintain that style. >>>>>>> >>>>>> >>>>>> Done. >>>>>> >>>>>> >>>>>>> >>>>>>> Please make sure that the changes you have done (explain output) >>>>>>> reflect in all the alt. expected output files. >>>>>>> >>>>>> >>>>>> Done. >>>>>> >>>>>> >>>>>>> Can you please see if we can eliminate the alternate expected >>>>>>> output files as well? What are the reasons we have to maintain those? >>>>>>> >>>>>> >>>>>> select_views.out and select_view_1.out are maintained by vanilla PG. >>>>>> We have added select_views_2.out and It can be removed, however I noticed >>>>>> that the test case that was added (Leaky View Scenario) is failing and >>>>>> needs a fix. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 24, 2013 at 10:59 PM, Abbas Butt < >>>>>>> abb...@en...> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> The test was failing because some more tests are added in sql file. >>>>>>>> >>>>>>>> -- >>>>>>>> *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> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> Try New Relic Now & We'll Send You this Cool Shirt >>>>>>>> New Relic is the only SaaS-based application performance monitoring >>>>>>>> service >>>>>>>> that delivers powerful full stack analytics. Optimize and monitor >>>>>>>> your >>>>>>>> browser, app, & servers with just a few lines of code. Try New Relic >>>>>>>> and get this awesome Nerd Life shirt! >>>>>>>> http://p.sf.net/sfu/newrelic_d2d_apr >>>>>>>> _______________________________________________ >>>>>>>> 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> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best Wishes, >>>>> Ashutosh Bapat >>>>> EntepriseDB Corporation >>>>> The Postgres Database Company >>>>> >>>> >>>> >>>> >>>> -- >>>> 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> >>> >> >> >> >> -- >> -- >> *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 > > -- StormDB - http://www.stormdb.com The Database Cloud |
|
From: Koichi S. <koi...@gm...> - 2013-05-09 13:19:27
|
Hmmm... This is not a simple issue to fix. Maybe we should document that the access privilege to the view must be the same as those of the base tables. Any other inputs to this? ---------- Koichi Suzuki 2013/5/9 Abbas Butt <abb...@en...> > Consider this test cases, which has been taken form select_views.sql and > simplified to pin point the issue. > > CREATE ROLE regress_alice; > CREATE TABLE customer(cid int primary key, name text not null, tel text, > passwd text); > > INSERT INTO customer VALUES > (101, 'regress_alice', '+81-12-3456-7890', 'passwd123'), > (102, 'regress_bob', '+01-234-567-8901', 'beafsteak'); > > CREATE VIEW my_property_normal AS SELECT * FROM customer; > > GRANT SELECT ON my_property_normal TO public; > > SET SESSION AUTHORIZATION regress_alice; > > > On PG > ===== > > test=> EXPLAIN VERBOSE SELECT * FROM my_property_normal; > QUERY PLAN > ---------------------------------------------------------------------- > Seq Scan on public.customer (cost=0.00..16.20 rows=620 width=100) > Output: customer.cid, customer.name, customer.tel, customer.passwd > (2 rows) > > test=> > test=> SELECT * FROM my_property_normal; > cid | name | tel | passwd > -----+---------------+------------------+----------- > 101 | regress_alice | +81-12-3456-7890 | passwd123 > 102 | regress_bob | +01-234-567-8901 | beafsteak > (2 rows) > > On XC > ===== > > test=> EXPLAIN VERBOSE SELECT * FROM my_property_normal; > QUERY PLAN > > --------------------------------------------------------------------------------------------------------------------- > Data Node Scan on "__REMOTE_FQS_QUERY__" (cost=0.00..0.00 rows=0 width=0) > Output: my_property_normal.cid, my_property_normal.name, > my_property_normal.tel, my_property_normal.passwd > Node/s: data_node_1, data_node_2, data_node_3, data_node_4 > Remote query: SELECT cid, name, tel, passwd FROM (SELECT customer.cid, > customer.name, customer.tel, customer.passwd FROM customer) > my_property_normal > (4 rows) > > test=> > test=> SELECT * FROM my_property_normal; > ERROR: permission denied for relation customer > > Please refer to the documentation at > http://www.postgresql.org/docs/9.2/static/rules-privileges.html > It says > "*Relations that are used due to rules get checked against the privileges > of the rule owner, not the user invoking the rule. This means that a user > only needs the required privileges for the tables/views that he names > explicitly in his queries.*" > > It is because of this fact that the query > SELECT * FROM my_property_normal > works fine when issued on PG. > In XC on the other hand, since views are not even created on datanodes, > they (datanodes) are not even aware that the query is actually a select > form a view, let alone enforcing the above statement in documentation. > > What strategy are we going to fix this problem? > Are we going to fix it or do some changes in documentation? > Regards > Abbas > > > > On Tue, May 7, 2013 at 11:38 AM, Abbas Butt <abb...@en...>wrote: > >> ok, sure. >> >> >> On Tue, May 7, 2013 at 11:37 AM, Ashutosh Bapat < >> ash...@en...> wrote: >> >>> BTW, fix the bug in separate patch and fix expected outputs in separate >>> patch. >>> >>> >>> On Tue, May 7, 2013 at 11:54 AM, Ashutosh Bapat < >>> ash...@en...> wrote: >>> >>>> Can you please fix the bug then? >>>> >>>> >>>> On Tue, May 7, 2013 at 10:25 AM, Abbas Butt < >>>> abb...@en...> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Apr 30, 2013 at 4:57 PM, Ashutosh Bapat < >>>>> ash...@en...> wrote: >>>>> >>>>>> Hi Abbas, >>>>>> I see that the EXPLAIN commands are changed to include the XC >>>>>> specific options. Since the original test is using capital letters >>>>>> everywhere, it's better to maintain that style. >>>>>> >>>>> >>>>> Done. >>>>> >>>>> >>>>>> >>>>>> Please make sure that the changes you have done (explain output) >>>>>> reflect in all the alt. expected output files. >>>>>> >>>>> >>>>> Done. >>>>> >>>>> >>>>>> Can you please see if we can eliminate the alternate expected output >>>>>> files as well? What are the reasons we have to maintain those? >>>>>> >>>>> >>>>> select_views.out and select_view_1.out are maintained by vanilla PG. >>>>> We have added select_views_2.out and It can be removed, however I noticed >>>>> that the test case that was added (Leaky View Scenario) is failing and >>>>> needs a fix. >>>>> >>>>> >>>>>> >>>>>> >>>>>> On Wed, Apr 24, 2013 at 10:59 PM, Abbas Butt < >>>>>> abb...@en...> wrote: >>>>>> >>>>>>> Hi, >>>>>>> The test was failing because some more tests are added in sql file. >>>>>>> >>>>>>> -- >>>>>>> *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> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Try New Relic Now & We'll Send You this Cool Shirt >>>>>>> New Relic is the only SaaS-based application performance monitoring >>>>>>> service >>>>>>> that delivers powerful full stack analytics. Optimize and monitor >>>>>>> your >>>>>>> browser, app, & servers with just a few lines of code. Try New Relic >>>>>>> and get this awesome Nerd Life shirt! >>>>>>> http://p.sf.net/sfu/newrelic_d2d_apr >>>>>>> _______________________________________________ >>>>>>> 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> >>>>> >>>> >>>> >>>> >>>> -- >>>> Best Wishes, >>>> Ashutosh Bapat >>>> EntepriseDB Corporation >>>> The Postgres Database Company >>>> >>> >>> >>> >>> -- >>> 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> >> > > > > -- > -- > *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-09 13:12:25
|
Let me take a look at it. I'd like to review/commit error correction and sequence backup to the slave first. Thank you; ---------- Koichi Suzuki 2013/5/9 Andrei Martsinchyk <and...@gm...> > So maybe attached fix would be acceptable? > It just disables loading of register.node with #if, no code is removed. > > > > 2013/5/9 鈴木 幸市 <ko...@in...> > >> Andrei; >> >> It's wonderful to have these fixes, especially sequence issues, which is >> already in the bug track. >> >> Error messages need some more thought, I think. Node registration will >> be useful in the future. Disabling this could be a quick fix but I think >> we should keep this code. >> >> Thank you very much; >> --- >> Koichi Suzuki >> >> >> >> On 2013/05/09, at 17:15, Andrei Martsinchyk <and...@gm...> >> wrote: >> >> 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 >> >> <missing_break.patch><create_sequence.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 >> >> >> > > > -- > 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: Abbas B. <abb...@en...> - 2013-05-09 13:11:16
|
Consider this test cases, which has been taken form select_views.sql and
simplified to pin point the issue.
CREATE ROLE regress_alice;
CREATE TABLE customer(cid int primary key, name text not null, tel text,
passwd text);
INSERT INTO customer VALUES
(101, 'regress_alice', '+81-12-3456-7890', 'passwd123'),
(102, 'regress_bob', '+01-234-567-8901', 'beafsteak');
CREATE VIEW my_property_normal AS SELECT * FROM customer;
GRANT SELECT ON my_property_normal TO public;
SET SESSION AUTHORIZATION regress_alice;
On PG
=====
test=> EXPLAIN VERBOSE SELECT * FROM my_property_normal;
QUERY PLAN
----------------------------------------------------------------------
Seq Scan on public.customer (cost=0.00..16.20 rows=620 width=100)
Output: customer.cid, customer.name, customer.tel, customer.passwd
(2 rows)
test=>
test=> SELECT * FROM my_property_normal;
cid | name | tel | passwd
-----+---------------+------------------+-----------
101 | regress_alice | +81-12-3456-7890 | passwd123
102 | regress_bob | +01-234-567-8901 | beafsteak
(2 rows)
On XC
=====
test=> EXPLAIN VERBOSE SELECT * FROM my_property_normal;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------
Data Node Scan on "__REMOTE_FQS_QUERY__" (cost=0.00..0.00 rows=0 width=0)
Output: my_property_normal.cid, my_property_normal.name,
my_property_normal.tel, my_property_normal.passwd
Node/s: data_node_1, data_node_2, data_node_3, data_node_4
Remote query: SELECT cid, name, tel, passwd FROM (SELECT customer.cid,
customer.name, customer.tel, customer.passwd FROM customer)
my_property_normal
(4 rows)
test=>
test=> SELECT * FROM my_property_normal;
ERROR: permission denied for relation customer
Please refer to the documentation at
http://www.postgresql.org/docs/9.2/static/rules-privileges.html
It says
"*Relations that are used due to rules get checked against the privileges
of the rule owner, not the user invoking the rule. This means that a user
only needs the required privileges for the tables/views that he names
explicitly in his queries.*"
It is because of this fact that the query
SELECT * FROM my_property_normal
works fine when issued on PG.
In XC on the other hand, since views are not even created on datanodes,
they (datanodes) are not even aware that the query is actually a select
form a view, let alone enforcing the above statement in documentation.
What strategy are we going to fix this problem?
Are we going to fix it or do some changes in documentation?
Regards
Abbas
On Tue, May 7, 2013 at 11:38 AM, Abbas Butt <abb...@en...>wrote:
> ok, sure.
>
>
> On Tue, May 7, 2013 at 11:37 AM, Ashutosh Bapat <
> ash...@en...> wrote:
>
>> BTW, fix the bug in separate patch and fix expected outputs in separate
>> patch.
>>
>>
>> On Tue, May 7, 2013 at 11:54 AM, Ashutosh Bapat <
>> ash...@en...> wrote:
>>
>>> Can you please fix the bug then?
>>>
>>>
>>> On Tue, May 7, 2013 at 10:25 AM, Abbas Butt <abb...@en...
>>> > wrote:
>>>
>>>>
>>>>
>>>> On Tue, Apr 30, 2013 at 4:57 PM, Ashutosh Bapat <
>>>> ash...@en...> wrote:
>>>>
>>>>> Hi Abbas,
>>>>> I see that the EXPLAIN commands are changed to include the XC specific
>>>>> options. Since the original test is using capital letters everywhere, it's
>>>>> better to maintain that style.
>>>>>
>>>>
>>>> Done.
>>>>
>>>>
>>>>>
>>>>> Please make sure that the changes you have done (explain output)
>>>>> reflect in all the alt. expected output files.
>>>>>
>>>>
>>>> Done.
>>>>
>>>>
>>>>> Can you please see if we can eliminate the alternate expected output
>>>>> files as well? What are the reasons we have to maintain those?
>>>>>
>>>>
>>>> select_views.out and select_view_1.out are maintained by vanilla PG. We
>>>> have added select_views_2.out and It can be removed, however I noticed that
>>>> the test case that was added (Leaky View Scenario) is failing and needs a
>>>> fix.
>>>>
>>>>
>>>>>
>>>>>
>>>>> On Wed, Apr 24, 2013 at 10:59 PM, Abbas Butt <
>>>>> abb...@en...> wrote:
>>>>>
>>>>>> Hi,
>>>>>> The test was failing because some more tests are added in sql file.
>>>>>>
>>>>>> --
>>>>>> *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>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Try New Relic Now & We'll Send You this Cool Shirt
>>>>>> New Relic is the only SaaS-based application performance monitoring
>>>>>> service
>>>>>> that delivers powerful full stack analytics. Optimize and monitor your
>>>>>> browser, app, & servers with just a few lines of code. Try New Relic
>>>>>> and get this awesome Nerd Life shirt!
>>>>>> http://p.sf.net/sfu/newrelic_d2d_apr
>>>>>> _______________________________________________
>>>>>> 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>
>>>>
>>>
>>>
>>>
>>> --
>>> Best Wishes,
>>> Ashutosh Bapat
>>> EntepriseDB Corporation
>>> The Postgres Database Company
>>>
>>
>>
>>
>> --
>> 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>
>
--
--
*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-09 12:44:20
|
Thanks Nikhil;
I reviewed and tested the patch. It looks nice. Old code used the
return value both as the status and sequence value, which brought
considerable confusion in the code. The patch solves this problem by
distinguishing return status and the value.
If there's no further imput, I'd like to commit it.
Then I will review Andrei's patch to improve gtm.
Regards;
----------
Koichi Suzuki
2013/4/30 Nikhil Sontakke <ni...@st...>
> PFA, patch which allows sequences with negative values.
>
> I have also added test cases in xc_sequence.sql.
>
> Regards,
> Nikhils
>
>
>
> On Mon, Apr 22, 2013 at 1:49 PM, Nikhil Sontakke <ni...@st...>wrote:
>
>> The currval() logic also has a similar issue.
>>
>> Regards,
>> Nikhils
>>
>>
>> On Mon, Apr 22, 2013 at 6:18 AM, 鈴木 幸市 <ko...@in...> wrote:
>>
>>> I'm afraid the cause is not only by gym. If min_value is not specified
>>> (or specified as "invalid" value), gtm assigns -0x7ffffffffffffffeLL as the
>>> minimum value of the sequence (see gtm_seq.[ch]). So I suspect that
>>> minimum value will be specified by DDL in the coordinator.
>>>
>>> You fix is very welcome.
>>>
>>> GTM in the current master has a backup feature which dumps next restore
>>> point of gxid and each sequence to gtm.control. I hope this helps tests
>>> to some extent.
>>>
>>> Regards;
>>> ---
>>> Koichi Suzuki
>>>
>>>
>>>
>>> On 2013/04/22, at 8:32, Michael Paquier <mic...@gm...>
>>> wrote:
>>>
>>>
>>>
>>>
>>> On Mon, Apr 22, 2013 at 3:57 AM, Nikhil Sontakke <ni...@st...>wrote:
>>>
>>>> Hi all,
>>>>
>>>> Consider the following:
>>>>
>>>> create sequence seqname increment by -2;
>>>> select nextval('seqname');
>>>> ERROR: GTM error, could not obtain sequence value
>>>>
>>>> The above should have returned -1.
>>>>
>>>> ISTM, the sequence fetching logic on the backend side has been coded
>>>> entirely with the assumption that sequences can never have negative values.
>>>> So a less than 0 value returned from get_next() is assumed to be a problem!
>>>> That's completely wrong. We need to deal with this properly. I will submit
>>>> a patch for this when I get some time soon.
>>>>
>>> Adding a regression test in xc_sequence.sql would also be good to cover
>>> this case as this is caused by xc-only code.
>>> --
>>> Michael
>>> ------------------------------------------------------------------------------
>>> Precog is a next-generation analytics platform capable of advanced
>>> analytics on semi-structured data. The platform includes APIs for
>>> building
>>> apps and a phenomenal toolset for data science. Developers can use
>>> our toolset for easy data analysis & visualization. Get a free account!
>>>
>>> http://www2.precog.com/precogplatform/slashdotnewsletter_______________________________________________
>>> Postgres-xc-developers mailing list
>>> Pos...@li...
>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>
>>>
>>>
>>
>>
>> --
>> StormDB - http://www.stormdb.com
>> The Database Cloud
>>
>
>
>
> --
> StormDB - http://www.stormdb.com
> The Database Cloud
>
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
>
|
261 messages has been excluded from this view by a project administrator.
