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: Michael P. <mic...@gm...> - 2013-02-25 01:13:39
|
On Mon, Feb 25, 2013 at 4:17 AM, Abbas Butt <abb...@en...>wrote: > > > On Sun, Feb 24, 2013 at 5:33 PM, Michael Paquier < > mic...@gm...> wrote: > >> >> >> On Sun, Feb 24, 2013 at 7:04 PM, Abbas Butt <abb...@en...>wrote: >> >>> >>> >>> On Sun, Feb 24, 2013 at 1:44 PM, Michael Paquier < >>> mic...@gm...> wrote: >>> >>>> >>>> >>>> On Sun, Feb 24, 2013 at 3:51 PM, Abbas Butt < >>>> abb...@en...> wrote: >>>> >>>>> Hi, >>>>> PFA a patch to fix pg_dump to generate TO NODE clause in the dump. >>>>> This is required because otherwise all tables get created on all nodes >>>>> after a dump-restore cycle. >>>>> >>>> Not sure this is good if you take a dump of an XC cluster to restore >>>> that to a vanilla Postgres cluster. >>>> Why not adding a new option that would control the generation of this >>>> clause instead of forcing it? >>>> >>> >>> I think you can use the pg_dump that comes with vanilla PG to do that, >>> can't you? But I am open to adding a control option if every body thinks so. >>> >> Sure you can, this is just to simplify the life of users a maximum by not >> having multiple pg_dump binaries in their serves. >> Saying that, I think that there is no option to choose if DISTRIBUTE BY >> is printed in the dump or not... >> > > Yah if we choose to have an option we will put both DISTRIBUTE BY and TO > NODE under it. > Why not an option for DISTRIBUTE BY, and another for TO NODE? This would bring more flexibility to the way dumps are generated. -- Michael |
|
From: Koichi S. <koi...@gm...> - 2013-02-25 01:08:00
|
Because we're continuing to use the same name pg_dump, users may easily be confused. I agree to add an option. ---------- Koichi Suzuki 2013/2/24 Abbas Butt <abb...@en...>: > > > On Sun, Feb 24, 2013 at 1:44 PM, Michael Paquier <mic...@gm...> > wrote: >> >> >> >> On Sun, Feb 24, 2013 at 3:51 PM, Abbas Butt <abb...@en...> >> wrote: >>> >>> Hi, >>> PFA a patch to fix pg_dump to generate TO NODE clause in the dump. >>> This is required because otherwise all tables get created on all nodes >>> after a dump-restore cycle. >> >> Not sure this is good if you take a dump of an XC cluster to restore that >> to a vanilla Postgres cluster. >> Why not adding a new option that would control the generation of this >> clause instead of forcing it? > > > I think you can use the pg_dump that comes with vanilla PG to do that, can't > you? But I am open to adding a control option if every body thinks so. > >> >> -- >> Michael > > > > > -- > -- > Abbas > Architect > EnterpriseDB Corporation > The Enterprise PostgreSQL Company > > Phone: 92-334-5100153 > > Website: www.enterprisedb.com > EnterpriseDB Blog: http://blogs.enterprisedb.com/ > Follow us on Twitter: http://www.twitter.com/enterprisedb > > This e-mail message (and any attachment) is intended for the use of > the individual or entity to whom it is addressed. This message > contains information from EnterpriseDB Corporation that may be > privileged, confidential, or exempt from disclosure under applicable > law. If you are not the intended recipient or authorized to receive > this for the intended recipient, any use, dissemination, distribution, > retention, archiving, or copying of this communication is strictly > prohibited. If you have received this e-mail in error, please notify > the sender immediately by reply e-mail and delete this message. > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > |
|
From: Abbas B. <abb...@en...> - 2013-02-24 19:18:22
|
On Sun, Feb 24, 2013 at 5:33 PM, Michael Paquier <mic...@gm...>wrote: > > > On Sun, Feb 24, 2013 at 7:04 PM, Abbas Butt <abb...@en...>wrote: > >> >> >> On Sun, Feb 24, 2013 at 1:44 PM, Michael Paquier < >> mic...@gm...> wrote: >> >>> >>> >>> On Sun, Feb 24, 2013 at 3:51 PM, Abbas Butt <abb...@en... >>> > wrote: >>> >>>> Hi, >>>> PFA a patch to fix pg_dump to generate TO NODE clause in the dump. >>>> This is required because otherwise all tables get created on all nodes >>>> after a dump-restore cycle. >>>> >>> Not sure this is good if you take a dump of an XC cluster to restore >>> that to a vanilla Postgres cluster. >>> Why not adding a new option that would control the generation of this >>> clause instead of forcing it? >>> >> >> I think you can use the pg_dump that comes with vanilla PG to do that, >> can't you? But I am open to adding a control option if every body thinks so. >> > Sure you can, this is just to simplify the life of users a maximum by not > having multiple pg_dump binaries in their serves. > Saying that, I think that there is no option to choose if DISTRIBUTE BY is > printed in the dump or not... > Yah if we choose to have an option we will put both DISTRIBUTE BY and TO NODE under it. > -- > Michael > -- -- Abbas Architect EnterpriseDB Corporation The Enterprise PostgreSQL Company Phone: 92-334-5100153 Website: www.enterprisedb.com EnterpriseDB Blog: http://blogs.enterprisedb.com/ Follow us on Twitter: http://www.twitter.com/enterprisedb This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message. |
|
From: Michael P. <mic...@gm...> - 2013-02-24 12:34:13
|
On Sun, Feb 24, 2013 at 7:04 PM, Abbas Butt <abb...@en...>wrote: > > > On Sun, Feb 24, 2013 at 1:44 PM, Michael Paquier < > mic...@gm...> wrote: > >> >> >> On Sun, Feb 24, 2013 at 3:51 PM, Abbas Butt <abb...@en...>wrote: >> >>> Hi, >>> PFA a patch to fix pg_dump to generate TO NODE clause in the dump. >>> This is required because otherwise all tables get created on all nodes >>> after a dump-restore cycle. >>> >> Not sure this is good if you take a dump of an XC cluster to restore that >> to a vanilla Postgres cluster. >> Why not adding a new option that would control the generation of this >> clause instead of forcing it? >> > > I think you can use the pg_dump that comes with vanilla PG to do that, > can't you? But I am open to adding a control option if every body thinks so. > Sure you can, this is just to simplify the life of users a maximum by not having multiple pg_dump binaries in their serves. Saying that, I think that there is no option to choose if DISTRIBUTE BY is printed in the dump or not... -- Michael |
|
From: Abbas B. <abb...@en...> - 2013-02-24 10:04:28
|
On Sun, Feb 24, 2013 at 1:44 PM, Michael Paquier <mic...@gm...>wrote: > > > On Sun, Feb 24, 2013 at 3:51 PM, Abbas Butt <abb...@en...>wrote: > >> Hi, >> PFA a patch to fix pg_dump to generate TO NODE clause in the dump. >> This is required because otherwise all tables get created on all nodes >> after a dump-restore cycle. >> > Not sure this is good if you take a dump of an XC cluster to restore that > to a vanilla Postgres cluster. > Why not adding a new option that would control the generation of this > clause instead of forcing it? > I think you can use the pg_dump that comes with vanilla PG to do that, can't you? But I am open to adding a control option if every body thinks so. > -- > Michael > -- -- Abbas Architect EnterpriseDB Corporation The Enterprise PostgreSQL Company Phone: 92-334-5100153 Website: www.enterprisedb.com EnterpriseDB Blog: http://blogs.enterprisedb.com/ Follow us on Twitter: http://www.twitter.com/enterprisedb This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message. |
|
From: Michael P. <mic...@gm...> - 2013-02-24 08:44:48
|
On Sun, Feb 24, 2013 at 3:51 PM, Abbas Butt <abb...@en...>wrote: > Hi, > PFA a patch to fix pg_dump to generate TO NODE clause in the dump. > This is required because otherwise all tables get created on all nodes > after a dump-restore cycle. > Not sure this is good if you take a dump of an XC cluster to restore that to a vanilla Postgres cluster. Why not adding a new option that would control the generation of this clause instead of forcing it? -- Michael |
|
From: Abbas B. <abb...@en...> - 2013-02-24 06:52:06
|
Hi, PFA a patch to fix pg_dump to generate TO NODE clause in the dump. This is required because otherwise all tables get created on all nodes after a dump-restore cycle. -- Abbas Architect EnterpriseDB Corporation The Enterprise PostgreSQL Company Phone: 92-334-5100153 Website: www.enterprisedb.com EnterpriseDB Blog: http://blogs.enterprisedb.com/ Follow us on Twitter: http://www.twitter.com/enterprisedb This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message. |
|
From: Abbas B. <abb...@en...> - 2013-02-23 09:29:31
|
Hi, PFA a patch to fix a crash when COPY TO is used on a replicated table. This test case produces a crash create table tab_rep(a int, b int) distribute by replication; insert into tab_rep values(1,2), (3,4), (5,6), (7,8); COPY tab_rep (a, b) TO stdout; Here is a description of the problem and the fix In case of a read from a replicated table GetRelationNodes() returns all nodes and expects that the planner can choose one depending on the rest of the join tree. In case of COPY TO we should choose the first one in the node list This fixes a system crash and makes pg_dump work fine. -- Abbas Architect EnterpriseDB Corporation The Enterprise PostgreSQL Company Phone: 92-334-5100153 Website: www.enterprisedb.com EnterpriseDB Blog: http://blogs.enterprisedb.com/ Follow us on Twitter: http://www.twitter.com/enterprisedb This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message. |
|
From: Koichi S. <koi...@gm...> - 2013-02-23 02:23:20
|
Could you try pgxc_pool_reload function? The hang is caused by pending connection/transaction in some of the pooler connections. This function info will be found at http://postgres-xc.sourceforge.net/docs/1_0_2/functions-admin.html Regards; ---------- Koichi Suzuki 2013/2/23 Venky Kandaswamy <ve...@ad...>: > Hello All, > We were doing some heavy volume testing by deleting and inserting blocks > of rows (using general delete and insert statements). We noticed that the > number of open sessions kept climbing, even though our client programs were > ended, and eventually reached around 1020 or so. At this point, we are no > longer able to issue our delete insert statements. We suspected that we > reached some kind of limit in PGXC, and that it was not reporting an error > but simply waiting. We have thoroughly checked our clients to make sure > there are no leaky connections. In fact, these are just plain java programs > that do a delete/insert of a day's data and then end. > > An strace of the application client program usually show a FUTEX_WAIT. > > An strace of a typical session shows that it is doing a " recvfrom(10, " > > We tried issuing a 'CLEAN CONNECTION TO ALL FORCE FOR DATABASE ADCHEMY", > but it was hanging also. The strace showed that it was doing a " recvmsg(11 > ". > > We are able to restart the cluster using pg_ctl 'immediate' option, but > not the 'fast' option. > > Our configuration has the following: > > 32 datanodes > max connections 1000 > max pool size 1000 > 8 coordinators > max connections 100 > max pool size 4000 > > Could one of you please tell me where we should start looking next? It > is evident that the number of 'sessions' is not going over a 1000 or so. > Thats where things start hanging. > > ________________________________________ > > Venky Kandaswamy > > Principal Engineer, Adchemy Inc. > > 925-200-7124 > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > |
|
From: Venky K. <ve...@ad...> - 2013-02-22 21:09:21
|
Hello All,
We were doing some heavy volume testing by deleting and inserting blocks of rows (using general delete and insert statements). We noticed that the number of open sessions kept climbing, even though our client programs were ended, and eventually reached around 1020 or so. At this point, we are no longer able to issue our delete insert statements. We suspected that we reached some kind of limit in PGXC, and that it was not reporting an error but simply waiting. We have thoroughly checked our clients to make sure there are no leaky connections. In fact, these are just plain java programs that do a delete/insert of a day's data and then end.
An strace of the application client program usually show a FUTEX_WAIT.
An strace of a typical session shows that it is doing a " recvfrom(10, "
We tried issuing a 'CLEAN CONNECTION TO ALL FORCE FOR DATABASE ADCHEMY", but it was hanging also. The strace showed that it was doing a " recvmsg(11 ".
We are able to restart the cluster using pg_ctl 'immediate' option, but not the 'fast' option.
Our configuration has the following:
32 datanodes
max connections 1000
max pool size 1000
8 coordinators
max connections 100
max pool size 4000
Could one of you please tell me where we should start looking next? It is evident that the number of 'sessions' is not going over a 1000 or so. Thats where things start hanging.
________________________________________
Venky Kandaswamy
Principal Engineer, Adchemy Inc.
925-200-7124
|
|
From: Koichi S. <koi...@gm...> - 2013-02-22 09:11:43
|
Thanks Abbas for the wonderful work. ---------- Koichi Suzuki 2013/2/19 Abbas Butt <abb...@en...>: > Hi, > Attached please find a patch that locks the cluster so that dump can be > taken to be restored on the new node to be added. > > To lock the cluster the patch adds a new GUC parameter called > xc_lock_for_backup, however its status is maintained by the pooler. The > reason is that the default behavior of XC is to release connections as soon > as a command is done and it uses PersistentConnections GUC to control the > behavior. We in this case however need a status that is independent of the > setting of PersistentConnections. > > Assume we have two coordinator cluster, the patch provides this behavior: > > Case 1: set and show > ==================== > psql test -p 5432 > set xc_lock_for_backup=yes; > show xc_lock_for_backup; > xc_lock_for_backup > -------------------- > yes > (1 row) > > Case 2: set from one client show from other > ================================== > psql test -p 5432 > set xc_lock_for_backup=yes; > (From another tab) > psql test -p 5432 > show xc_lock_for_backup; > xc_lock_for_backup > -------------------- > yes > (1 row) > > Case 3: set from one, quit it, run again and show > ====================================== > psql test -p 5432 > set xc_lock_for_backup=yes; > \q > psql test -p 5432 > show xc_lock_for_backup; > xc_lock_for_backup > -------------------- > yes > (1 row) > > Case 4: set on one coordinator, show from other > ===================================== > psql test -p 5432 > set xc_lock_for_backup=yes; > (From another tab) > psql test -p 5433 > show xc_lock_for_backup; > xc_lock_for_backup > -------------------- > yes > (1 row) > > pg_dump and pg_dumpall seem to work fine after locking the cluster for > backup but I would test these utilities in detail next. > > Also I have yet to look in detail that standard_ProcessUtility is the only > place that updates the portion of catalog that is dumped. There may be some > other places too that need to be blocked for catalog updates. > > The patch adds no extra warnings and regression shows no extra failure. > > Comments are welcome. > > -- > Abbas > Architect > EnterpriseDB Corporation > The Enterprise PostgreSQL Company > > Phone: 92-334-5100153 > > Website: www.enterprisedb.com > EnterpriseDB Blog: http://blogs.enterprisedb.com/ > Follow us on Twitter: http://www.twitter.com/enterprisedb > > This e-mail message (and any attachment) is intended for the use of > the individual or entity to whom it is addressed. This message > contains information from EnterpriseDB Corporation that may be > privileged, confidential, or exempt from disclosure under applicable > law. If you are not the intended recipient or authorized to receive > this for the intended recipient, any use, dissemination, distribution, > retention, archiving, or copying of this communication is strictly > prohibited. If you have received this e-mail in error, please notify > the sender immediately by reply e-mail and delete this message. > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > |
|
From: Koichi S. <koi...@gm...> - 2013-02-22 03:13:00
|
Changing the macro into a function does not solve the issue. It does not eliminate the need to acquire the lock. Adding comment to the macro definition is reasonable compromise. Regards; ---------- Koichi Suzuki 2013/2/22 Michael Paquier <mic...@gm...>: > Thanks. Applied. > > On Fri, Feb 22, 2013 at 12:41 AM, Nikhil Sontakke <ni...@st...> > wrote: >> >> Or we can even remove this macro to be on the safe side. > > Not sure, it looks pretty useful to do that as a macro for transaction count > control. > -- > Michael > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > |
|
From: Michael P. <mic...@gm...> - 2013-02-21 23:08:16
|
Thanks. Applied. On Fri, Feb 22, 2013 at 12:41 AM, Nikhil Sontakke <ni...@st...>wrote: > Or we can even remove this macro to be on the safe side. > Not sure, it looks pretty useful to do that as a macro for transaction count control. -- Michael |
|
From: Nikhil S. <ni...@st...> - 2013-02-21 15:49:32
|
Hi, In gtm_txn.h we have this macro: #define GTM_CountOpenTransactions() (gtm_list_length(GTMTransactions.gt_open_transactions)) If this macro is called without taking a lock on gt_TransArrayLock then it can return spurious results. Currently it's not used anywhere so we are safe. I thought of adding a READ lock to gt_TransArrayLock inside the macro itself, but it's possible that the caller is already holding the lock. So I thought it best to add a comment above this macro. Or we can even remove this macro to be on the safe side. Regards, Nikhils -- StormDB - http://www.stormdb.com The Database Cloud Postgres-XC Support and Service |
|
From: Koichi S. <koi...@gm...> - 2013-02-21 10:28:44
|
Hello, I found that "select 1" does now work to detect datanode/coordinator crash correctly when gtm/gtm_proxy crashes. When gtm/gtm_proxy crashes, "select 1" returns error and monitoring program (HA middleware or other operation support program) determine coordinator/datanode crashes, which is wrong. So we need another means to detect coordinator/datanode is running but gtm/gtm_proxy crashed. One solution will be to make "select 1" not to return error. In this case, we may need another means to detect if coordinator/datanode crashes. It could be very complicated and lead to allow very inconsistent view visible. I think cleaner solution is to provide "watchdog" to tell that sever loop is running and is ready to accept connections. I understand this is duplicate implementation in the case of PostgreSQL itself but is needed for XC. I also understand that this could conflict when PG itself implement similar feature. This kind of risk is found in many other places in XC and I believe watchdog timer is a good solution for monitoring coordinator/datanode independent from gtm status. Any feedbacks? ---------- Koichi Suzuki |
|
From: Koichi S. <koi...@gm...> - 2013-02-21 08:28:30
|
Okay. I hope this satisfies everybody.
----------
Koichi Suzuki
2013/2/20 Ashutosh Bapat <ash...@en...>:
>
>
> On Wed, Feb 20, 2013 at 10:49 AM, Xiong Wang <wan...@gm...> wrote:
>>
>> Hi Ashutosh,
>>
>> 2013/2/6 Ashutosh Bapat <ash...@en...>
>>>
>>> Hi Xiong,
>>>
>>> On Tue, Feb 5, 2013 at 8:06 PM, Xiong Wang <wan...@gm...>
>>> wrote:
>>>>
>>>> Hi Ashutosh,
>>>> 2013/2/5 Ashutosh Bapat <ash...@en...>
>>>>>
>>>>> Hi Xiong,
>>>>> Thanks for the patch. It's very much awaited feature.
>>>>>
>>>>> Here are some comments on your patch.
>>>>>
>>>>> The patch applies well, but has some unwanted white spaces
>>>>> [ashutosh@ubuntu coderoot]git apply
>>>>> /mnt/hgfs/tmp/print_distribution_info.patch
>>>>> /mnt/hgfs/tmp/print_distribution_info.patch:28: space before tab in
>>>>> indent.
>>>>> "SELECT CASE pclocatortype \n"
>>>>> /mnt/hgfs/tmp/print_distribution_info.patch:35: trailing whitespace.
>>>>> "WHEN '%c' THEN 'MODULO' END || ' ('|| a.attname
>>>>> ||')' as distype\n"
>>>>> /mnt/hgfs/tmp/print_distribution_info.patch:59: trailing whitespace.
>>>>>
>>>>> warning: 3 lines add whitespace errors.
>>>>> Please take care of those.
>>>>
>>>>
>>>> Thanks for your patient review. I will fix these problems.
>>>>
>>>>>
>>>>>
>>>>> I see that there are comments like /* NOTICE: The number of beginning
>>>>> whitespace is the same as index print */ followed by printing of a message
>>>>> with some spaces hard-coded in it. I do not see this style being used
>>>>> anywhere in the file and it looks problematic. If it happens that this new
>>>>> information is indented, the hard-coded spaces will not align properly. Can
>>>>> you please check what's the proper way of aligning the lines and use that
>>>>> method?
>>>>
>>>> I add this notice deliberately because the length of white spaces before
>>>> printing index information is 4. There is no warn similar with my comment in
>>>> describe.c. So, I will delete this comment within later patch. Thanks again.
>>>>
>>>
>>>
>>> Don't just delete the comment, we need to get rid of hardcoded white
>>> spaces. Do you see any other instance in the file which uses white spaces?
>>
>>
>> Yes. There are several other places use hardcoded white spaces such as
>> printing constraints including check, fk and printing trigger informations.
>> In order to follow postgresql style, I will just delete my comments.
>>>
>>>
>>>>>
>>>>> Instead of following query,
>>>>> 1742 "SELECT node_name FROM
>>>>> pg_catalog.pgxc_node \n"
>>>>> 1743 "WHERE oid::text in \n"
>>>>> 1744 "(SELECT
>>>>> pg_catalog.regexp_split_to_table(nodeoids::text, E'\\\\s+') FROM
>>>>> pg_catalog.pgxc_class WHERE pcrelid = '%s');"
>>>>>
>>>>> I would use (with proper indentation)
>>>>> SELECT ARRAY(SELECT node_name FROM pg_catalog.pgxc_node WHERE oid IN
>>>>> (SELECT unnest(nodeoids) FROM pgxc_class WHERE pcrelid = %s));
>>>>> This query will give you only one row containing all the nodes. Using
>>>>> unnest to convert an array to table and then using IN operator is better
>>>>> than converting array to string and using split on string, and then
>>>>> combining the result back. That way, we don't rely on the syntax of array to
>>>>> string conversion or any particular regular expression.
>>>>
>>>> Great. I didn't find the unnest function. I will change my query later.
>>>>
>>>>>
>>>>> Please provide the fix for the failing regressions as well. You will
>>>>> need to change the expected output.
>>>>
>>>> As for regression failure, I wanted to submit the fixing patch but my
>>>> test environment is different from yours. I doubt that my patch for fixing
>>>> the failure may be not useful.
>>>>
>>>
>>>
>>> Send the expected output changes anyway, we will have to find out a way
>>> to fix the regression.
>>
>> Ok.
>>
>
> Now you have a way to fix the regression as well. Use ALL DATANODES if the
> list of nodes contains all the datanodes. We have just seen one objection.
> Printing ALL DATANODES looks to have uses other than silencing regressions.
> So, it's worth putting it.
>
>>
>> Thanks & Regards
>> Benny Wang
>>>>
>>>>
>>>>>
>>>>> Rest of the patch looks good.
>>>>>
>>>>> On Tue, Feb 5, 2013 at 11:41 AM, Xiong Wang <wan...@gm...>
>>>>> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> The enclosure is the patch for showing distribution information.
>>>>>>
>>>>>> Two sql files, inherit.sql and create_table_like.sql in the regression
>>>>>> test will fail.
>>>>>>
>>>>>> Thanks & Regards,
>>>>>>
>>>>>> Benny Wang
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2013/2/1 Koichi Suzuki <koi...@gm...>
>>>>>>>
>>>>>>> Yes, it's nice to have.
>>>>>>>
>>>>>>> I understand there were many discuttions to have it, separate command
>>>>>>> or \d and \d+. \d, \d+ extension will not be affected by command
>>>>>>> name conflict. I hope we can handle further change both in XC and
>>>>>>> PG. I don't see very big difference in comparison of
>>>>>>> separate/existing command. Their pros and cons seems to be
>>>>>>> comparable. So I think we can decide what is more convenient to
>>>>>>> use.
>>>>>>> So far, I understand more people prefer \d. It's quite okay with
>>>>>>> me.
>>>>>>>
>>>>>>> In addition, we may want to see each node information (resource,
>>>>>>> primary, preferred) and configuration of each nodegroup. Because
>>>>>>> this
>>>>>>> is quite new to XC, I think it's better to have xc-specific command
>>>>>>> such as \xc something.
>>>>>>>
>>>>>>> Regards;
>>>>>>> ----------
>>>>>>> Koichi Suzuki
>>>>>>>
>>>>>>>
>>>>>>> 2013/2/1 Xiong Wang <wan...@gm...>:
>>>>>>> > Hi Suzuki,
>>>>>>> > According to Ashutosh and ANikhil, It seems that they want to print
>>>>>>> > distributed method as well as the location node list using \d+ .
>>>>>>> > Are you in favor?
>>>>>>> >
>>>>>>> > Regards,
>>>>>>> > Benny
>>>>>>> >
>>>>>>> >
>>>>>>> > 2013/2/1 Koichi Suzuki <koi...@gm...>
>>>>>>> >>
>>>>>>> >> One more issue,
>>>>>>> >>
>>>>>>> >> Does anybody need a command to print node list from pgxc_node and
>>>>>>> >> pgxc_group?
>>>>>>> >> ----------
>>>>>>> >> Koichi Suzuki
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> 2013/2/1 Koichi Suzuki <koi...@gm...>:
>>>>>>> >> > Great!
>>>>>>> >> >
>>>>>>> >> > Benny, please post your patch when ready.
>>>>>>> >> > ----------
>>>>>>> >> > Koichi Suzuki
>>>>>>> >> >
>>>>>>> >> >
>>>>>>> >> > 2013/2/1 Mason Sharp <ma...@st...>:
>>>>>>> >> >>
>>>>>>> >> >>
>>>>>>> >> >> On Thu, Jan 31, 2013 at 5:38 AM, Ashutosh Bapat
>>>>>>> >> >> <ash...@en...> wrote:
>>>>>>> >> >>>
>>>>>>> >> >>> +1. We should add this functionality as \d+.
>>>>>>> >> >>
>>>>>>> >> >>
>>>>>>> >> >> +1
>>>>>>> >> >>
>>>>>>> >> >>>
>>>>>>> >> >>>
>>>>>>> >> >>> Xion,
>>>>>>> >> >>> You will need to output the nodes where the table is
>>>>>>> >> >>> distributed or
>>>>>>> >> >>> replicated.
>>>>>>> >> >>>
>>>>>>> >> >>>
>>>>>>> >> >>> On Thu, Jan 31, 2013 at 3:11 PM, Nikhil Sontakke
>>>>>>> >> >>> <ni...@st...>
>>>>>>> >> >>> wrote:
>>>>>>> >> >>>>
>>>>>>> >> >>>> Btw, I vote for showing PGXC output with \d+ and other
>>>>>>> >> >>>> extended
>>>>>>> >> >>>> commands
>>>>>>> >> >>>> only.
>>>>>>> >> >>>>
>>>>>>> >> >>>> Nikhils
>>>>>>> >> >>>>
>>>>>>> >> >>>> On Thu, Jan 31, 2013 at 3:08 PM, Nikhil Sontakke
>>>>>>> >> >>>> <ni...@st...>
>>>>>>> >> >>>> wrote:
>>>>>>> >> >>>> > I still do not understand how showing additional stuff in
>>>>>>> >> >>>> > the PGXC
>>>>>>> >> >>>> > version makes it incompatible with vanilla Postgres?
>>>>>>> >> >>>> >
>>>>>>> >> >>>> > As you can see, the OP made changes to the *existing* \d
>>>>>>> >> >>>> > logic
>>>>>>> >> >>>> > which
>>>>>>> >> >>>> > is a logical way of doing things. As long as we use #ifdef
>>>>>>> >> >>>> > PGXC, I
>>>>>>> >> >>>> > do
>>>>>>> >> >>>> > not see how printing additional info breaks anything.
>>>>>>> >> >>>> > Infact it
>>>>>>> >> >>>> > avoids
>>>>>>> >> >>>> > users having to learn more stuff.
>>>>>>> >> >>>> >
>>>>>>> >> >>>> > Regards,
>>>>>>> >> >>>> > Nikhils
>>>>>>> >> >>>> >
>>>>>>> >> >>>> > On Thu, Jan 31, 2013 at 2:59 PM, Michael Paquier
>>>>>>> >> >>>> > <mic...@gm...> wrote:
>>>>>>> >> >>>> >> On Thu, Jan 31, 2013 at 6:04 PM, Xiong Wang
>>>>>>> >> >>>> >> <wan...@gm...>
>>>>>>> >> >>>> >> wrote:
>>>>>>> >> >>>> >>>
>>>>>>> >> >>>> >>> I wrote a simple patch which will show distribution
>>>>>>> >> >>>> >>> information
>>>>>>> >> >>>> >>> when
>>>>>>> >> >>>> >>> you
>>>>>>> >> >>>> >>> use \d tablename command.
>>>>>>> >> >>>> >>
>>>>>>> >> >>>> >> I vote no for that with ¥d. I agree it is useful, but it
>>>>>>> >> >>>> >> makes the
>>>>>>> >> >>>> >> output
>>>>>>> >> >>>> >> inconsistent with vanilla Postgres. And I am sure it
>>>>>>> >> >>>> >> creates many
>>>>>>> >> >>>> >> failures
>>>>>>> >> >>>> >> in regression tests. It has been discussed before to use
>>>>>>> >> >>>> >> either a
>>>>>>> >> >>>> >> new
>>>>>>> >> >>>> >> command with a word or a letter we'll be sure won't be in
>>>>>>> >> >>>> >> conflict
>>>>>>> >> >>>> >> with
>>>>>>> >> >>>> >> vanilla now and at some point in the future. Something
>>>>>>> >> >>>> >> like
>>>>>>> >> >>>> >> "¥distrib"
>>>>>>> >> >>>> >> perhaps?
>>>>>>> >> >>>> >> --
>>>>>>> >> >>>> >> Michael Paquier
>>>>>>> >> >>>> >> http://michael.otacoo.com
>>>>>>> >> >>>> >>
>>>>>>> >> >>>> >>
>>>>>>> >> >>>> >>
>>>>>>> >> >>>> >> ------------------------------------------------------------------------------
>>>>>>> >> >>>> >> Everyone hates slow websites. So do we.
>>>>>>> >> >>>> >> Make your web apps faster with AppDynamics
>>>>>>> >> >>>> >> Download AppDynamics Lite for free today:
>>>>>>> >> >>>> >> http://p.sf.net/sfu/appdyn_d2d_jan
>>>>>>> >> >>>> >> _______________________________________________
>>>>>>> >> >>>> >> Postgres-xc-developers mailing list
>>>>>>> >> >>>> >> Pos...@li...
>>>>>>> >> >>>> >>
>>>>>>> >> >>>> >>
>>>>>>> >> >>>> >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>>> >> >>>> >>
>>>>>>> >> >>>> >
>>>>>>> >> >>>> >
>>>>>>> >> >>>> >
>>>>>>> >> >>>> > --
>>>>>>> >> >>>> > StormDB - http://www.stormdb.com
>>>>>>> >> >>>> > The Database Cloud
>>>>>>> >> >>>> > Postgres-XC Support and Service
>>>>>>> >> >>>>
>>>>>>> >> >>>>
>>>>>>> >> >>>>
>>>>>>> >> >>>> --
>>>>>>> >> >>>> StormDB - http://www.stormdb.com
>>>>>>> >> >>>> The Database Cloud
>>>>>>> >> >>>> Postgres-XC Support and Service
>>>>>>> >> >>>>
>>>>>>> >> >>>>
>>>>>>> >> >>>>
>>>>>>> >> >>>>
>>>>>>> >> >>>> ------------------------------------------------------------------------------
>>>>>>> >> >>>> Everyone hates slow websites. So do we.
>>>>>>> >> >>>> Make your web apps faster with AppDynamics
>>>>>>> >> >>>> Download AppDynamics Lite for free today:
>>>>>>> >> >>>> http://p.sf.net/sfu/appdyn_d2d_jan
>>>>>>> >> >>>> _______________________________________________
>>>>>>> >> >>>> Postgres-xc-developers mailing list
>>>>>>> >> >>>> Pos...@li...
>>>>>>> >> >>>>
>>>>>>> >> >>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>>> >> >>>
>>>>>>> >> >>>
>>>>>>> >> >>>
>>>>>>> >> >>>
>>>>>>> >> >>> --
>>>>>>> >> >>> Best Wishes,
>>>>>>> >> >>> Ashutosh Bapat
>>>>>>> >> >>> EntepriseDB Corporation
>>>>>>> >> >>> The Enterprise Postgres Company
>>>>>>> >> >>>
>>>>>>> >> >>>
>>>>>>> >> >>>
>>>>>>> >> >>>
>>>>>>> >> >>> ------------------------------------------------------------------------------
>>>>>>> >> >>> Everyone hates slow websites. So do we.
>>>>>>> >> >>> Make your web apps faster with AppDynamics
>>>>>>> >> >>> Download AppDynamics Lite for free today:
>>>>>>> >> >>> http://p.sf.net/sfu/appdyn_d2d_jan
>>>>>>> >> >>> _______________________________________________
>>>>>>> >> >>> Postgres-xc-developers mailing list
>>>>>>> >> >>> Pos...@li...
>>>>>>> >> >>>
>>>>>>> >> >>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>>> >> >>>
>>>>>>> >> >>
>>>>>>> >> >>
>>>>>>> >> >>
>>>>>>> >> >> --
>>>>>>> >> >> Mason Sharp
>>>>>>> >> >>
>>>>>>> >> >>
>>>>>>> >> >> StormDB - http://www.stormdb.com
>>>>>>> >> >> The Database Cloud
>>>>>>> >> >> Postgres-XC Support and Services
>>>>>>> >> >>
>>>>>>> >> >>
>>>>>>> >> >> ------------------------------------------------------------------------------
>>>>>>> >> >> Everyone hates slow websites. So do we.
>>>>>>> >> >> Make your web apps faster with AppDynamics
>>>>>>> >> >> Download AppDynamics Lite for free today:
>>>>>>> >> >> http://p.sf.net/sfu/appdyn_d2d_jan
>>>>>>> >> >> _______________________________________________
>>>>>>> >> >> Postgres-xc-developers mailing list
>>>>>>> >> >> Pos...@li...
>>>>>>> >> >>
>>>>>>> >> >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>>> >> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> ------------------------------------------------------------------------------
>>>>>>> >> Everyone hates slow websites. So do we.
>>>>>>> >> Make your web apps faster with AppDynamics
>>>>>>> >> Download AppDynamics Lite for free today:
>>>>>>> >> http://p.sf.net/sfu/appdyn_d2d_jan
>>>>>>> >> _______________________________________________
>>>>>>> >> Postgres-xc-developers mailing list
>>>>>>> >> Pos...@li...
>>>>>>> >>
>>>>>>> >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>>> >
>>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Free Next-Gen Firewall Hardware Offer
>>>>>> Buy your Sophos next-gen firewall before the end March 2013
>>>>>> and get the hardware for free! Learn more.
>>>>>> http://p.sf.net/sfu/sophos-d2d-feb
>>>>>> _______________________________________________
>>>>>> Postgres-xc-developers mailing list
>>>>>> Pos...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best Wishes,
>>>>> Ashutosh Bapat
>>>>> EntepriseDB Corporation
>>>>> The Enterprise Postgres Company
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Best Wishes,
>>> Ashutosh Bapat
>>> EntepriseDB Corporation
>>> The Enterprise Postgres Company
>>
>>
>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>
|
|
From: Koichi S. <koi...@gm...> - 2013-02-21 08:20:31
|
Year, make check can be done with a fixed set of names but make installcheck is another. Maybe pgxc_ctl can be extended to provide some help for this. Regards; ---------- Koichi Suzuki 2013/2/19 Michael Paquier <mic...@gm...>: > > > On Tue, Feb 19, 2013 at 7:11 PM, Koichi Suzuki <koi...@gm...> > wrote: >> >> Regression test will create two coordinators and datanodes with fixed >> names. In this case, we don't have to worry about the names. >> Anyway, we have to rewrite affected test cases, which could take time. >> I'm worrying about this. > > On the contrary, you have to worry about the names as well, make > installcheck should work with the same transparency as make check. > -- > Michael |
|
From: Nikhil S. <ni...@st...> - 2013-02-20 14:01:32
|
Self answer: Ok, I see code in the transaction code path which retries the connection. So, maybe autovac etc. ignores connection failure, prints out the warning and goes away.. Regards, Nikhils On Wed, Feb 20, 2013 at 7:08 PM, Nikhil Sontakke <ni...@st...> wrote: > In the InitGTM function if the connection to the GTM does not succeed, > we print out a WARNING. > > "can not connect to GTM: Connection timed out" > > Shouldn't it be an error? What will the transaction do without a GTM? > Or we have code which re-connects later whenever needed to the GTM? > > Regards, > Nikhils > -- > StormDB - http://www.stormdb.com > The Database Cloud > Postgres-XC Support and Service -- StormDB - http://www.stormdb.com The Database Cloud Postgres-XC Support and Service |
|
From: Nikhil S. <ni...@st...> - 2013-02-20 13:39:07
|
In the InitGTM function if the connection to the GTM does not succeed, we print out a WARNING. "can not connect to GTM: Connection timed out" Shouldn't it be an error? What will the transaction do without a GTM? Or we have code which re-connects later whenever needed to the GTM? Regards, Nikhils -- StormDB - http://www.stormdb.com The Database Cloud Postgres-XC Support and Service |
|
From: Ashutosh B. <ash...@en...> - 2013-02-20 05:41:45
|
On Wed, Feb 20, 2013 at 10:49 AM, Xiong Wang <wan...@gm...> wrote:
> Hi Ashutosh,
>
> 2013/2/6 Ashutosh Bapat <ash...@en...>
>
>> Hi Xiong,
>>
>> On Tue, Feb 5, 2013 at 8:06 PM, Xiong Wang <wan...@gm...>wrote:
>>
>>> Hi Ashutosh,
>>> 2013/2/5 Ashutosh Bapat <ash...@en...>
>>>
>>>> Hi Xiong,
>>>> Thanks for the patch. It's very much awaited feature.
>>>>
>>>> Here are some comments on your patch.
>>>>
>>>> The patch applies well, but has some unwanted white spaces
>>>> [ashutosh@ubuntu coderoot]git apply
>>>> /mnt/hgfs/tmp/print_distribution_info.patch
>>>> /mnt/hgfs/tmp/print_distribution_info.patch:28: space before tab in
>>>> indent.
>>>> "SELECT CASE pclocatortype \n"
>>>> /mnt/hgfs/tmp/print_distribution_info.patch:35: trailing whitespace.
>>>> "WHEN '%c' THEN 'MODULO' END || ' ('|| a.attname
>>>> ||')' as distype\n"
>>>> /mnt/hgfs/tmp/print_distribution_info.patch:59: trailing whitespace.
>>>>
>>>> warning: 3 lines add whitespace errors.
>>>> Please take care of those.
>>>>
>>>
>>> Thanks for your patient review. I will fix these problems.
>>>
>>>
>>>>
>>>> I see that there are comments like /* NOTICE: The number of beginning
>>>> whitespace is the same as index print */ followed by printing of a message
>>>> with some spaces hard-coded in it. I do not see this style being used
>>>> anywhere in the file and it looks problematic. If it happens that this new
>>>> information is indented, the hard-coded spaces will not align properly. Can
>>>> you please check what's the proper way of aligning the lines and use that
>>>> method?
>>>>
>>> I add this notice deliberately because the length of white spaces before
>>> printing index information is 4. There is no warn similar with my
>>> comment in describe.c. So, I will delete this comment within later patch.
>>> Thanks again.
>>>
>>>
>>
>> Don't just delete the comment, we need to get rid of hardcoded white
>> spaces. Do you see any other instance in the file which uses white spaces?
>>
>
> Yes. There are several other places use hardcoded white spaces such as
> printing constraints including check, fk and printing trigger informations.
> In order to follow postgresql style, I will just delete my comments.
>
>>
>>
>>> Instead of following query,
>>>> 1742 "SELECT node_name FROM
>>>> pg_catalog.pgxc_node \n"
>>>> 1743 "WHERE oid::text in \n"
>>>> 1744 "(SELECT
>>>> pg_catalog.regexp_split_to_table(nodeoids::text, E'\\\\s+') FROM
>>>> pg_catalog.pgxc_class WHERE pcrelid = '%s');"
>>>>
>>>> I would use (with proper indentation)
>>>> SELECT ARRAY(SELECT node_name FROM pg_catalog.pgxc_node WHERE oid IN
>>>> (SELECT unnest(nodeoids) FROM pgxc_class WHERE pcrelid = %s));
>>>> This query will give you only one row containing all the nodes. Using
>>>> unnest to convert an array to table and then using IN operator is better
>>>> than converting array to string and using split on string, and then
>>>> combining the result back. That way, we don't rely on the syntax of array
>>>> to string conversion or any particular regular expression.
>>>>
>>> Great. I didn't find the unnest function. I will change my query later.
>>>
>>>
>>>> Please provide the fix for the failing regressions as well. You will
>>>> need to change the expected output.
>>>>
>>> As for regression failure, I wanted to submit the fixing patch but my
>>> test environment is different from yours. I doubt that my patch for fixing
>>> the failure may be not useful.
>>>
>>>
>>
>> Send the expected output changes anyway, we will have to find out a way
>> to fix the regression.
>>
> Ok.
>
>
Now you have a way to fix the regression as well. Use ALL DATANODES if the
list of nodes contains all the datanodes. We have just seen one objection.
Printing ALL DATANODES looks to have uses other than silencing regressions.
So, it's worth putting it.
> Thanks & Regards
> Benny Wang
>
>>
>>>
>>>> Rest of the patch looks good.
>>>>
>>>> On Tue, Feb 5, 2013 at 11:41 AM, Xiong Wang <wan...@gm...>wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> The enclosure is the patch for showing distribution information.
>>>>>
>>>>> Two sql files, inherit.sql and create_table_like.sql in the regression
>>>>> test will fail.
>>>>>
>>>>> Thanks & Regards,
>>>>>
>>>>> Benny Wang
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2013/2/1 Koichi Suzuki <koi...@gm...>
>>>>>
>>>>>> Yes, it's nice to have.
>>>>>>
>>>>>> I understand there were many discuttions to have it, separate command
>>>>>> or \d and \d+. \d, \d+ extension will not be affected by command
>>>>>> name conflict. I hope we can handle further change both in XC and
>>>>>> PG. I don't see very big difference in comparison of
>>>>>> separate/existing command. Their pros and cons seems to be
>>>>>> comparable. So I think we can decide what is more convenient to use.
>>>>>> So far, I understand more people prefer \d. It's quite okay with
>>>>>> me.
>>>>>>
>>>>>> In addition, we may want to see each node information (resource,
>>>>>> primary, preferred) and configuration of each nodegroup. Because this
>>>>>> is quite new to XC, I think it's better to have xc-specific command
>>>>>> such as \xc something.
>>>>>>
>>>>>> Regards;
>>>>>> ----------
>>>>>> Koichi Suzuki
>>>>>>
>>>>>>
>>>>>> 2013/2/1 Xiong Wang <wan...@gm...>:
>>>>>> > Hi Suzuki,
>>>>>> > According to Ashutosh and ANikhil, It seems that they want to print
>>>>>> > distributed method as well as the location node list using \d+ .
>>>>>> > Are you in favor?
>>>>>> >
>>>>>> > Regards,
>>>>>> > Benny
>>>>>> >
>>>>>> >
>>>>>> > 2013/2/1 Koichi Suzuki <koi...@gm...>
>>>>>> >>
>>>>>> >> One more issue,
>>>>>> >>
>>>>>> >> Does anybody need a command to print node list from pgxc_node and
>>>>>> >> pgxc_group?
>>>>>> >> ----------
>>>>>> >> Koichi Suzuki
>>>>>> >>
>>>>>> >>
>>>>>> >> 2013/2/1 Koichi Suzuki <koi...@gm...>:
>>>>>> >> > Great!
>>>>>> >> >
>>>>>> >> > Benny, please post your patch when ready.
>>>>>> >> > ----------
>>>>>> >> > Koichi Suzuki
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > 2013/2/1 Mason Sharp <ma...@st...>:
>>>>>> >> >>
>>>>>> >> >>
>>>>>> >> >> On Thu, Jan 31, 2013 at 5:38 AM, Ashutosh Bapat
>>>>>> >> >> <ash...@en...> wrote:
>>>>>> >> >>>
>>>>>> >> >>> +1. We should add this functionality as \d+.
>>>>>> >> >>
>>>>>> >> >>
>>>>>> >> >> +1
>>>>>> >> >>
>>>>>> >> >>>
>>>>>> >> >>>
>>>>>> >> >>> Xion,
>>>>>> >> >>> You will need to output the nodes where the table is
>>>>>> distributed or
>>>>>> >> >>> replicated.
>>>>>> >> >>>
>>>>>> >> >>>
>>>>>> >> >>> On Thu, Jan 31, 2013 at 3:11 PM, Nikhil Sontakke <
>>>>>> ni...@st...>
>>>>>> >> >>> wrote:
>>>>>> >> >>>>
>>>>>> >> >>>> Btw, I vote for showing PGXC output with \d+ and other
>>>>>> extended
>>>>>> >> >>>> commands
>>>>>> >> >>>> only.
>>>>>> >> >>>>
>>>>>> >> >>>> Nikhils
>>>>>> >> >>>>
>>>>>> >> >>>> On Thu, Jan 31, 2013 at 3:08 PM, Nikhil Sontakke
>>>>>> >> >>>> <ni...@st...>
>>>>>> >> >>>> wrote:
>>>>>> >> >>>> > I still do not understand how showing additional stuff in
>>>>>> the PGXC
>>>>>> >> >>>> > version makes it incompatible with vanilla Postgres?
>>>>>> >> >>>> >
>>>>>> >> >>>> > As you can see, the OP made changes to the *existing* \d
>>>>>> logic
>>>>>> >> >>>> > which
>>>>>> >> >>>> > is a logical way of doing things. As long as we use #ifdef
>>>>>> PGXC, I
>>>>>> >> >>>> > do
>>>>>> >> >>>> > not see how printing additional info breaks anything.
>>>>>> Infact it
>>>>>> >> >>>> > avoids
>>>>>> >> >>>> > users having to learn more stuff.
>>>>>> >> >>>> >
>>>>>> >> >>>> > Regards,
>>>>>> >> >>>> > Nikhils
>>>>>> >> >>>> >
>>>>>> >> >>>> > On Thu, Jan 31, 2013 at 2:59 PM, Michael Paquier
>>>>>> >> >>>> > <mic...@gm...> wrote:
>>>>>> >> >>>> >> On Thu, Jan 31, 2013 at 6:04 PM, Xiong Wang
>>>>>> >> >>>> >> <wan...@gm...>
>>>>>> >> >>>> >> wrote:
>>>>>> >> >>>> >>>
>>>>>> >> >>>> >>> I wrote a simple patch which will show distribution
>>>>>> information
>>>>>> >> >>>> >>> when
>>>>>> >> >>>> >>> you
>>>>>> >> >>>> >>> use \d tablename command.
>>>>>> >> >>>> >>
>>>>>> >> >>>> >> I vote no for that with ¥d. I agree it is useful, but it
>>>>>> makes the
>>>>>> >> >>>> >> output
>>>>>> >> >>>> >> inconsistent with vanilla Postgres. And I am sure it
>>>>>> creates many
>>>>>> >> >>>> >> failures
>>>>>> >> >>>> >> in regression tests. It has been discussed before to use
>>>>>> either a
>>>>>> >> >>>> >> new
>>>>>> >> >>>> >> command with a word or a letter we'll be sure won't be in
>>>>>> conflict
>>>>>> >> >>>> >> with
>>>>>> >> >>>> >> vanilla now and at some point in the future. Something like
>>>>>> >> >>>> >> "¥distrib"
>>>>>> >> >>>> >> perhaps?
>>>>>> >> >>>> >> --
>>>>>> >> >>>> >> Michael Paquier
>>>>>> >> >>>> >> http://michael.otacoo.com
>>>>>> >> >>>> >>
>>>>>> >> >>>> >>
>>>>>> >> >>>> >>
>>>>>> ------------------------------------------------------------------------------
>>>>>> >> >>>> >> Everyone hates slow websites. So do we.
>>>>>> >> >>>> >> Make your web apps faster with AppDynamics
>>>>>> >> >>>> >> Download AppDynamics Lite for free today:
>>>>>> >> >>>> >> http://p.sf.net/sfu/appdyn_d2d_jan
>>>>>> >> >>>> >> _______________________________________________
>>>>>> >> >>>> >> Postgres-xc-developers mailing list
>>>>>> >> >>>> >> Pos...@li...
>>>>>> >> >>>> >>
>>>>>> >> >>>> >>
>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>> >> >>>> >>
>>>>>> >> >>>> >
>>>>>> >> >>>> >
>>>>>> >> >>>> >
>>>>>> >> >>>> > --
>>>>>> >> >>>> > StormDB - http://www.stormdb.com
>>>>>> >> >>>> > The Database Cloud
>>>>>> >> >>>> > Postgres-XC Support and Service
>>>>>> >> >>>>
>>>>>> >> >>>>
>>>>>> >> >>>>
>>>>>> >> >>>> --
>>>>>> >> >>>> StormDB - http://www.stormdb.com
>>>>>> >> >>>> The Database Cloud
>>>>>> >> >>>> Postgres-XC Support and Service
>>>>>> >> >>>>
>>>>>> >> >>>>
>>>>>> >> >>>>
>>>>>> >> >>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> >> >>>> Everyone hates slow websites. So do we.
>>>>>> >> >>>> Make your web apps faster with AppDynamics
>>>>>> >> >>>> Download AppDynamics Lite for free today:
>>>>>> >> >>>> http://p.sf.net/sfu/appdyn_d2d_jan
>>>>>> >> >>>> _______________________________________________
>>>>>> >> >>>> Postgres-xc-developers mailing list
>>>>>> >> >>>> Pos...@li...
>>>>>> >> >>>>
>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>> >> >>>
>>>>>> >> >>>
>>>>>> >> >>>
>>>>>> >> >>>
>>>>>> >> >>> --
>>>>>> >> >>> Best Wishes,
>>>>>> >> >>> Ashutosh Bapat
>>>>>> >> >>> EntepriseDB Corporation
>>>>>> >> >>> The Enterprise Postgres Company
>>>>>> >> >>>
>>>>>> >> >>>
>>>>>> >> >>>
>>>>>> >> >>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> >> >>> Everyone hates slow websites. So do we.
>>>>>> >> >>> Make your web apps faster with AppDynamics
>>>>>> >> >>> Download AppDynamics Lite for free today:
>>>>>> >> >>> http://p.sf.net/sfu/appdyn_d2d_jan
>>>>>> >> >>> _______________________________________________
>>>>>> >> >>> Postgres-xc-developers mailing list
>>>>>> >> >>> Pos...@li...
>>>>>> >> >>>
>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>> >> >>>
>>>>>> >> >>
>>>>>> >> >>
>>>>>> >> >>
>>>>>> >> >> --
>>>>>> >> >> Mason Sharp
>>>>>> >> >>
>>>>>> >> >>
>>>>>> >> >> StormDB - http://www.stormdb.com
>>>>>> >> >> The Database Cloud
>>>>>> >> >> Postgres-XC Support and Services
>>>>>> >> >>
>>>>>> >> >>
>>>>>> ------------------------------------------------------------------------------
>>>>>> >> >> Everyone hates slow websites. So do we.
>>>>>> >> >> Make your web apps faster with AppDynamics
>>>>>> >> >> Download AppDynamics Lite for free today:
>>>>>> >> >> http://p.sf.net/sfu/appdyn_d2d_jan
>>>>>> >> >> _______________________________________________
>>>>>> >> >> Postgres-xc-developers mailing list
>>>>>> >> >> Pos...@li...
>>>>>> >> >>
>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>> >> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> ------------------------------------------------------------------------------
>>>>>> >> Everyone hates slow websites. So do we.
>>>>>> >> Make your web apps faster with AppDynamics
>>>>>> >> Download AppDynamics Lite for free today:
>>>>>> >> http://p.sf.net/sfu/appdyn_d2d_jan
>>>>>> >> _______________________________________________
>>>>>> >> Postgres-xc-developers mailing list
>>>>>> >> Pos...@li...
>>>>>> >>
>>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>> >
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Free Next-Gen Firewall Hardware Offer
>>>>> Buy your Sophos next-gen firewall before the end March 2013
>>>>> and get the hardware for free! Learn more.
>>>>> http://p.sf.net/sfu/sophos-d2d-feb
>>>>> _______________________________________________
>>>>> Postgres-xc-developers mailing list
>>>>> Pos...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best Wishes,
>>>> Ashutosh Bapat
>>>> EntepriseDB Corporation
>>>> The Enterprise Postgres Company
>>>>
>>>
>>>
>>
>>
>> --
>> Best Wishes,
>> Ashutosh Bapat
>> EntepriseDB Corporation
>> The Enterprise Postgres Company
>>
>
>
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
|
|
From: Xiong W. <wan...@gm...> - 2013-02-20 05:20:00
|
Hi Ashutosh,
2013/2/6 Ashutosh Bapat <ash...@en...>
> Hi Xiong,
>
> On Tue, Feb 5, 2013 at 8:06 PM, Xiong Wang <wan...@gm...> wrote:
>
>> Hi Ashutosh,
>> 2013/2/5 Ashutosh Bapat <ash...@en...>
>>
>>> Hi Xiong,
>>> Thanks for the patch. It's very much awaited feature.
>>>
>>> Here are some comments on your patch.
>>>
>>> The patch applies well, but has some unwanted white spaces
>>> [ashutosh@ubuntu coderoot]git apply
>>> /mnt/hgfs/tmp/print_distribution_info.patch
>>> /mnt/hgfs/tmp/print_distribution_info.patch:28: space before tab in
>>> indent.
>>> "SELECT CASE pclocatortype \n"
>>> /mnt/hgfs/tmp/print_distribution_info.patch:35: trailing whitespace.
>>> "WHEN '%c' THEN 'MODULO' END || ' ('|| a.attname
>>> ||')' as distype\n"
>>> /mnt/hgfs/tmp/print_distribution_info.patch:59: trailing whitespace.
>>>
>>> warning: 3 lines add whitespace errors.
>>> Please take care of those.
>>>
>>
>> Thanks for your patient review. I will fix these problems.
>>
>>
>>>
>>> I see that there are comments like /* NOTICE: The number of beginning
>>> whitespace is the same as index print */ followed by printing of a message
>>> with some spaces hard-coded in it. I do not see this style being used
>>> anywhere in the file and it looks problematic. If it happens that this new
>>> information is indented, the hard-coded spaces will not align properly. Can
>>> you please check what's the proper way of aligning the lines and use that
>>> method?
>>>
>> I add this notice deliberately because the length of white spaces before
>> printing index information is 4. There is no warn similar with my
>> comment in describe.c. So, I will delete this comment within later patch.
>> Thanks again.
>>
>>
>
> Don't just delete the comment, we need to get rid of hardcoded white
> spaces. Do you see any other instance in the file which uses white spaces?
>
Yes. There are several other places use hardcoded white spaces such as
printing constraints including check, fk and printing trigger informations.
In order to follow postgresql style, I will just delete my comments.
>
>
>> Instead of following query,
>>> 1742 "SELECT node_name FROM pg_catalog.pgxc_node
>>> \n"
>>> 1743 "WHERE oid::text in \n"
>>> 1744 "(SELECT
>>> pg_catalog.regexp_split_to_table(nodeoids::text, E'\\\\s+') FROM
>>> pg_catalog.pgxc_class WHERE pcrelid = '%s');"
>>>
>>> I would use (with proper indentation)
>>> SELECT ARRAY(SELECT node_name FROM pg_catalog.pgxc_node WHERE oid IN
>>> (SELECT unnest(nodeoids) FROM pgxc_class WHERE pcrelid = %s));
>>> This query will give you only one row containing all the nodes. Using
>>> unnest to convert an array to table and then using IN operator is better
>>> than converting array to string and using split on string, and then
>>> combining the result back. That way, we don't rely on the syntax of array
>>> to string conversion or any particular regular expression.
>>>
>> Great. I didn't find the unnest function. I will change my query later.
>>
>>
>>> Please provide the fix for the failing regressions as well. You will
>>> need to change the expected output.
>>>
>> As for regression failure, I wanted to submit the fixing patch but my
>> test environment is different from yours. I doubt that my patch for fixing
>> the failure may be not useful.
>>
>>
>
> Send the expected output changes anyway, we will have to find out a way to
> fix the regression.
>
Ok.
Thanks & Regards
Benny Wang
>
>>
>>> Rest of the patch looks good.
>>>
>>> On Tue, Feb 5, 2013 at 11:41 AM, Xiong Wang <wan...@gm...>wrote:
>>>
>>>> Hi all,
>>>>
>>>> The enclosure is the patch for showing distribution information.
>>>>
>>>> Two sql files, inherit.sql and create_table_like.sql in the regression
>>>> test will fail.
>>>>
>>>> Thanks & Regards,
>>>>
>>>> Benny Wang
>>>>
>>>>
>>>>
>>>>
>>>> 2013/2/1 Koichi Suzuki <koi...@gm...>
>>>>
>>>>> Yes, it's nice to have.
>>>>>
>>>>> I understand there were many discuttions to have it, separate command
>>>>> or \d and \d+. \d, \d+ extension will not be affected by command
>>>>> name conflict. I hope we can handle further change both in XC and
>>>>> PG. I don't see very big difference in comparison of
>>>>> separate/existing command. Their pros and cons seems to be
>>>>> comparable. So I think we can decide what is more convenient to use.
>>>>> So far, I understand more people prefer \d. It's quite okay with
>>>>> me.
>>>>>
>>>>> In addition, we may want to see each node information (resource,
>>>>> primary, preferred) and configuration of each nodegroup. Because this
>>>>> is quite new to XC, I think it's better to have xc-specific command
>>>>> such as \xc something.
>>>>>
>>>>> Regards;
>>>>> ----------
>>>>> Koichi Suzuki
>>>>>
>>>>>
>>>>> 2013/2/1 Xiong Wang <wan...@gm...>:
>>>>> > Hi Suzuki,
>>>>> > According to Ashutosh and ANikhil, It seems that they want to print
>>>>> > distributed method as well as the location node list using \d+ .
>>>>> > Are you in favor?
>>>>> >
>>>>> > Regards,
>>>>> > Benny
>>>>> >
>>>>> >
>>>>> > 2013/2/1 Koichi Suzuki <koi...@gm...>
>>>>> >>
>>>>> >> One more issue,
>>>>> >>
>>>>> >> Does anybody need a command to print node list from pgxc_node and
>>>>> >> pgxc_group?
>>>>> >> ----------
>>>>> >> Koichi Suzuki
>>>>> >>
>>>>> >>
>>>>> >> 2013/2/1 Koichi Suzuki <koi...@gm...>:
>>>>> >> > Great!
>>>>> >> >
>>>>> >> > Benny, please post your patch when ready.
>>>>> >> > ----------
>>>>> >> > Koichi Suzuki
>>>>> >> >
>>>>> >> >
>>>>> >> > 2013/2/1 Mason Sharp <ma...@st...>:
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> On Thu, Jan 31, 2013 at 5:38 AM, Ashutosh Bapat
>>>>> >> >> <ash...@en...> wrote:
>>>>> >> >>>
>>>>> >> >>> +1. We should add this functionality as \d+.
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> +1
>>>>> >> >>
>>>>> >> >>>
>>>>> >> >>>
>>>>> >> >>> Xion,
>>>>> >> >>> You will need to output the nodes where the table is
>>>>> distributed or
>>>>> >> >>> replicated.
>>>>> >> >>>
>>>>> >> >>>
>>>>> >> >>> On Thu, Jan 31, 2013 at 3:11 PM, Nikhil Sontakke <
>>>>> ni...@st...>
>>>>> >> >>> wrote:
>>>>> >> >>>>
>>>>> >> >>>> Btw, I vote for showing PGXC output with \d+ and other extended
>>>>> >> >>>> commands
>>>>> >> >>>> only.
>>>>> >> >>>>
>>>>> >> >>>> Nikhils
>>>>> >> >>>>
>>>>> >> >>>> On Thu, Jan 31, 2013 at 3:08 PM, Nikhil Sontakke
>>>>> >> >>>> <ni...@st...>
>>>>> >> >>>> wrote:
>>>>> >> >>>> > I still do not understand how showing additional stuff in
>>>>> the PGXC
>>>>> >> >>>> > version makes it incompatible with vanilla Postgres?
>>>>> >> >>>> >
>>>>> >> >>>> > As you can see, the OP made changes to the *existing* \d
>>>>> logic
>>>>> >> >>>> > which
>>>>> >> >>>> > is a logical way of doing things. As long as we use #ifdef
>>>>> PGXC, I
>>>>> >> >>>> > do
>>>>> >> >>>> > not see how printing additional info breaks anything. Infact
>>>>> it
>>>>> >> >>>> > avoids
>>>>> >> >>>> > users having to learn more stuff.
>>>>> >> >>>> >
>>>>> >> >>>> > Regards,
>>>>> >> >>>> > Nikhils
>>>>> >> >>>> >
>>>>> >> >>>> > On Thu, Jan 31, 2013 at 2:59 PM, Michael Paquier
>>>>> >> >>>> > <mic...@gm...> wrote:
>>>>> >> >>>> >> On Thu, Jan 31, 2013 at 6:04 PM, Xiong Wang
>>>>> >> >>>> >> <wan...@gm...>
>>>>> >> >>>> >> wrote:
>>>>> >> >>>> >>>
>>>>> >> >>>> >>> I wrote a simple patch which will show distribution
>>>>> information
>>>>> >> >>>> >>> when
>>>>> >> >>>> >>> you
>>>>> >> >>>> >>> use \d tablename command.
>>>>> >> >>>> >>
>>>>> >> >>>> >> I vote no for that with ¥d. I agree it is useful, but it
>>>>> makes the
>>>>> >> >>>> >> output
>>>>> >> >>>> >> inconsistent with vanilla Postgres. And I am sure it
>>>>> creates many
>>>>> >> >>>> >> failures
>>>>> >> >>>> >> in regression tests. It has been discussed before to use
>>>>> either a
>>>>> >> >>>> >> new
>>>>> >> >>>> >> command with a word or a letter we'll be sure won't be in
>>>>> conflict
>>>>> >> >>>> >> with
>>>>> >> >>>> >> vanilla now and at some point in the future. Something like
>>>>> >> >>>> >> "¥distrib"
>>>>> >> >>>> >> perhaps?
>>>>> >> >>>> >> --
>>>>> >> >>>> >> Michael Paquier
>>>>> >> >>>> >> http://michael.otacoo.com
>>>>> >> >>>> >>
>>>>> >> >>>> >>
>>>>> >> >>>> >>
>>>>> ------------------------------------------------------------------------------
>>>>> >> >>>> >> Everyone hates slow websites. So do we.
>>>>> >> >>>> >> Make your web apps faster with AppDynamics
>>>>> >> >>>> >> Download AppDynamics Lite for free today:
>>>>> >> >>>> >> http://p.sf.net/sfu/appdyn_d2d_jan
>>>>> >> >>>> >> _______________________________________________
>>>>> >> >>>> >> Postgres-xc-developers mailing list
>>>>> >> >>>> >> Pos...@li...
>>>>> >> >>>> >>
>>>>> >> >>>> >>
>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>> >> >>>> >>
>>>>> >> >>>> >
>>>>> >> >>>> >
>>>>> >> >>>> >
>>>>> >> >>>> > --
>>>>> >> >>>> > StormDB - http://www.stormdb.com
>>>>> >> >>>> > The Database Cloud
>>>>> >> >>>> > Postgres-XC Support and Service
>>>>> >> >>>>
>>>>> >> >>>>
>>>>> >> >>>>
>>>>> >> >>>> --
>>>>> >> >>>> StormDB - http://www.stormdb.com
>>>>> >> >>>> The Database Cloud
>>>>> >> >>>> Postgres-XC Support and Service
>>>>> >> >>>>
>>>>> >> >>>>
>>>>> >> >>>>
>>>>> >> >>>>
>>>>> ------------------------------------------------------------------------------
>>>>> >> >>>> Everyone hates slow websites. So do we.
>>>>> >> >>>> Make your web apps faster with AppDynamics
>>>>> >> >>>> Download AppDynamics Lite for free today:
>>>>> >> >>>> http://p.sf.net/sfu/appdyn_d2d_jan
>>>>> >> >>>> _______________________________________________
>>>>> >> >>>> Postgres-xc-developers mailing list
>>>>> >> >>>> Pos...@li...
>>>>> >> >>>>
>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>> >> >>>
>>>>> >> >>>
>>>>> >> >>>
>>>>> >> >>>
>>>>> >> >>> --
>>>>> >> >>> Best Wishes,
>>>>> >> >>> Ashutosh Bapat
>>>>> >> >>> EntepriseDB Corporation
>>>>> >> >>> The Enterprise Postgres Company
>>>>> >> >>>
>>>>> >> >>>
>>>>> >> >>>
>>>>> >> >>>
>>>>> ------------------------------------------------------------------------------
>>>>> >> >>> Everyone hates slow websites. So do we.
>>>>> >> >>> Make your web apps faster with AppDynamics
>>>>> >> >>> Download AppDynamics Lite for free today:
>>>>> >> >>> http://p.sf.net/sfu/appdyn_d2d_jan
>>>>> >> >>> _______________________________________________
>>>>> >> >>> Postgres-xc-developers mailing list
>>>>> >> >>> Pos...@li...
>>>>> >> >>>
>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>> >> >>>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> --
>>>>> >> >> Mason Sharp
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> StormDB - http://www.stormdb.com
>>>>> >> >> The Database Cloud
>>>>> >> >> Postgres-XC Support and Services
>>>>> >> >>
>>>>> >> >>
>>>>> ------------------------------------------------------------------------------
>>>>> >> >> Everyone hates slow websites. So do we.
>>>>> >> >> Make your web apps faster with AppDynamics
>>>>> >> >> Download AppDynamics Lite for free today:
>>>>> >> >> http://p.sf.net/sfu/appdyn_d2d_jan
>>>>> >> >> _______________________________________________
>>>>> >> >> Postgres-xc-developers mailing list
>>>>> >> >> Pos...@li...
>>>>> >> >>
>>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>> >> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> ------------------------------------------------------------------------------
>>>>> >> Everyone hates slow websites. So do we.
>>>>> >> Make your web apps faster with AppDynamics
>>>>> >> Download AppDynamics Lite for free today:
>>>>> >> http://p.sf.net/sfu/appdyn_d2d_jan
>>>>> >> _______________________________________________
>>>>> >> Postgres-xc-developers mailing list
>>>>> >> Pos...@li...
>>>>> >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>> >
>>>>> >
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Free Next-Gen Firewall Hardware Offer
>>>> Buy your Sophos next-gen firewall before the end March 2013
>>>> and get the hardware for free! Learn more.
>>>> http://p.sf.net/sfu/sophos-d2d-feb
>>>> _______________________________________________
>>>> Postgres-xc-developers mailing list
>>>> Pos...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>>>>
>>>>
>>>
>>>
>>> --
>>> Best Wishes,
>>> Ashutosh Bapat
>>> EntepriseDB Corporation
>>> The Enterprise Postgres Company
>>>
>>
>>
>
>
> --
> Best Wishes,
> Ashutosh Bapat
> EntepriseDB Corporation
> The Enterprise Postgres Company
>
|
|
From: Michael P. <mic...@gm...> - 2013-02-19 11:12:40
|
On Tue, Feb 19, 2013 at 7:11 PM, Koichi Suzuki <koi...@gm...>wrote: > Regression test will create two coordinators and datanodes with fixed > names. In this case, we don't have to worry about the names. > Anyway, we have to rewrite affected test cases, which could take time. > I'm worrying about this. > On the contrary, you have to worry about the names as well, make installcheck should work with the same transparency as make check. -- Michael |
|
From: Koichi S. <koi...@gm...> - 2013-02-19 10:56:53
|
I'm afraid the discussion is going to "all-or-nothing" direction. Apparently, there's a case where we can determine the target datanode at planning, as well as the opposite case. Of course, cache invalidation is another issue to consider, when we determine the target datanode at the planning. So the issue looks to be: 1) How we determine when to determine actual target node, 2) If target node is determined at planning and the cache invalidated, how to recover from this. Regards; ---------- Koichi Suzuki 2013/2/15 Ashutosh Bapat <ash...@en...>: > > > On Fri, Feb 15, 2013 at 11:19 AM, Nikhil Sontakke <ni...@st...> > wrote: >> >> >> > There is no way for the second session to know that there are >> >> > prepared >> >> > statements out there, so there is no stopping it from changing the >> >> > preferred >> >> > nodes. At the same time, I do not see any need to do so. Preferred >> >> > node >> >> > should be a dynamic non-blocking setting, very handy to tackle the >> >> > network >> >> > dynamics if needed. >> >> > >> >> >> >> In this case the plan cache should be invalidated and re-built afresh. >> >> The case should be similar to when the involved relations in a plan >> >> undergo a change AFAICS. >> >> >> > >> > When we can take care of this stuff (and without much change in the >> > code), >> > without plan cache invalidation, why to go the route of cache >> > invalidation? >> > Plan cache invalidation is a heavy operation in itself and its >> > consequences >> > cause performance degradation. Because of plan invalidation all those >> > plans >> > which are really not affected by this change, would be hit too. >> > >> >> You make this node ddl stuff sound like a routine activity. It's going >> to be once in a while, right? >> > > You seem to have forgot the other argument I made about inserts not being > well-balanced for round-robin tables, which is another argument I have put > forth for this change. > >> >> Regards, >> Nikhils >> -- >> StormDB - http://www.stormdb.com >> The Database Cloud >> Postgres-XC Support and Service > > > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Enterprise Postgres Company > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > |
|
From: Ashutosh B. <ash...@en...> - 2013-02-19 10:17:54
|
Suzuki-san, We haven't yet standardized any regression environment. The one you are talking about is what NTT uses. I use a different one and I am sure everybody else has their own. We took a lot of efforts while writing xc specific tests to make sure that our tests run and pass on variety of regression environments so that developers do not have to stick to one or the other environment. I think we should continue to do that. On Tue, Feb 19, 2013 at 3:41 PM, Koichi Suzuki <koi...@gm...>wrote: > Regression test will create two coordinators and datanodes with fixed > names. In this case, we don't have to worry about the names. > Anyway, we have to rewrite affected test cases, which could take time. > I'm worrying about this. > > Xion, sorry for taking this long. Maybe it's much better to have > separate command or to use pre-defined views. > > Any more thoughts? > ---------- > Koichi Suzuki > > > 2013/2/19 Nikhil Sontakke <ni...@st...>: > > Hi, > > > >> According to Ashutosh Bapat, could we just print ALL NODES if the count > of > >> nodelist is the same as the count of datanodes, otherwise print the node > >> list. By this way, the regression test will be resolved. > >> > > > > Umm, I don't particularly like this idea of printing "ALL DATANODES" > > just to make regressions work... > > > > Can we not document that the standard testing environment should have > > a so and so config with recommended names for coordinators and > > datanodes? > > > > Regards, > > Nikhils > > > > > >> Thanks & Regards, > >> > >> Benny Wang > >> > >> 2013/2/15 Ashutosh Bapat <ash...@en...> > >>> > >>> > >>> > >>> On Fri, Feb 15, 2013 at 8:28 AM, Koichi Suzuki < > koi...@gm...> > >>> wrote: > >>>> > >>>> I found \d+ is used 41 times in the regression. If we extend \d+ > >>>> with table distribution, we need to (continue to) modify all of them. > >>>> Is it too much? > >>>> > >>> > >>> I don't see regression expected output changes to be of a lot of > concern. > >>> We can do them ones and for all. There might be some merge conflicts > later, > >>> but that's something, which would part of our ongoing merge. That's > >>> inevitable for a project like XC, which pulls from PG. > >>> > >>> My concern is different. \d+ or \d whatever, would start printing the > list > >>> of nodes the table is distributed on, which will be dependent upon the > >>> individual's enviroment, and names and number of nodes chosen. So, > tests > >>> passing for one would not do so for someone else. So, we will need > some way > >>> to canonicalize the list of nodes so that it comes out to be same > >>> independent of the environment. > >>> > >>> I suggest this, instead of \d+ printing the individual nodes, it first > >>> looks at the node groups for a matching node group and prints the name > of > >>> group if it finds one matching. Next, if all the datanodes are in the > list > >>> of nodes, it would print ALL DATANODES or something like that. Since > the > >>> regression tests use default node list, which has all datanodes, for > almost > >>> (I am sure all) all \d+ outputs we will get ALL DATANODES, which will > be > >>> independent of the environment used. > >>> > >>>> > >>>> Regards; > >>>> ---------- > >>>> Koichi Suzuki > >>>> > >>>> > >>>> 2013/2/14 Michael Paquier <mic...@gm...>: > >>>> > > >>>> > > >>>> > On Thu, Feb 14, 2013 at 7:44 PM, Nikhil Sontakke < > ni...@st...> > >>>> > wrote: > >>>> >> > >>>> >> Michael seems to be doing a see-saw here :) > >>>> > > >>>> > After doing manually regression merges for 9.1 and 9.2 on more than > 50 > >>>> > regression tests for each merge, you learn quite a bit... Making it > >>>> > more > >>>> > painful will just consume more time than necessary. > >>>> > > >>>> >> On some other thread he seemed ok to extend \d+ > >>>> > > >>>> > Call that experience, I was OK with with ¥d+ before actually having > a > >>>> > look > >>>> > at the number of tests using it. > >>>> > -- > >>>> > Michael > >>>> > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> Free Next-Gen Firewall Hardware Offer > >>>> Buy your Sophos next-gen firewall before the end March 2013 > >>>> and get the hardware for free! Learn more. > >>>> http://p.sf.net/sfu/sophos-d2d-feb > >>>> _______________________________________________ > >>>> Postgres-xc-developers mailing list > >>>> Pos...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > >>> > >>> > >>> > >>> > >>> -- > >>> Best Wishes, > >>> Ashutosh Bapat > >>> EntepriseDB Corporation > >>> The Enterprise Postgres Company > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> Free Next-Gen Firewall Hardware Offer > >>> Buy your Sophos next-gen firewall before the end March 2013 > >>> and get the hardware for free! Learn more. > >>> http://p.sf.net/sfu/sophos-d2d-feb > >>> _______________________________________________ > >>> Postgres-xc-developers mailing list > >>> Pos...@li... > >>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > >>> > >> > >> > >> > ------------------------------------------------------------------------------ > >> Everyone hates slow websites. So do we. > >> Make your web apps faster with AppDynamics > >> Download AppDynamics Lite for free today: > >> http://p.sf.net/sfu/appdyn_d2d_feb > >> _______________________________________________ > >> Postgres-xc-developers mailing list > >> Pos...@li... > >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > >> > > > > > > > > -- > > StormDB - http://www.stormdb.com > > The Database Cloud > > Postgres-XC Support and Service > > > > > ------------------------------------------------------------------------------ > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_d2d_feb > > _______________________________________________ > > Postgres-xc-developers mailing list > > Pos...@li... > > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Enterprise Postgres Company |
|
From: Ashutosh B. <ash...@en...> - 2013-02-19 10:14:58
|
On Tue, Feb 19, 2013 at 1:32 PM, Nikhil Sontakke <ni...@st...>wrote: > Hi, > > > According to Ashutosh Bapat, could we just print ALL NODES if the count > of > > nodelist is the same as the count of datanodes, otherwise print the node > > list. By this way, the regression test will be resolved. > > > > Umm, I don't particularly like this idea of printing "ALL DATANODES" > just to make regressions work... > > Making regressions work is one thing, but it will be good for user to know that the table is distributed/replicated on "ALL" nodes rather than nodes d1, d2, d3, .., dn. It becomes easy for the user to spot whether a table intended to be on all nodes is that way or not. > Can we not document that the standard testing environment should have > a so and so config with recommended names for coordinators and > datanodes? > > Regards, > Nikhils > > > > Thanks & Regards, > > > > Benny Wang > > > > 2013/2/15 Ashutosh Bapat <ash...@en...> > >> > >> > >> > >> On Fri, Feb 15, 2013 at 8:28 AM, Koichi Suzuki < > koi...@gm...> > >> wrote: > >>> > >>> I found \d+ is used 41 times in the regression. If we extend \d+ > >>> with table distribution, we need to (continue to) modify all of them. > >>> Is it too much? > >>> > >> > >> I don't see regression expected output changes to be of a lot of > concern. > >> We can do them ones and for all. There might be some merge conflicts > later, > >> but that's something, which would part of our ongoing merge. That's > >> inevitable for a project like XC, which pulls from PG. > >> > >> My concern is different. \d+ or \d whatever, would start printing the > list > >> of nodes the table is distributed on, which will be dependent upon the > >> individual's enviroment, and names and number of nodes chosen. So, tests > >> passing for one would not do so for someone else. So, we will need some > way > >> to canonicalize the list of nodes so that it comes out to be same > >> independent of the environment. > >> > >> I suggest this, instead of \d+ printing the individual nodes, it first > >> looks at the node groups for a matching node group and prints the name > of > >> group if it finds one matching. Next, if all the datanodes are in the > list > >> of nodes, it would print ALL DATANODES or something like that. Since the > >> regression tests use default node list, which has all datanodes, for > almost > >> (I am sure all) all \d+ outputs we will get ALL DATANODES, which will be > >> independent of the environment used. > >> > >>> > >>> Regards; > >>> ---------- > >>> Koichi Suzuki > >>> > >>> > >>> 2013/2/14 Michael Paquier <mic...@gm...>: > >>> > > >>> > > >>> > On Thu, Feb 14, 2013 at 7:44 PM, Nikhil Sontakke < > ni...@st...> > >>> > wrote: > >>> >> > >>> >> Michael seems to be doing a see-saw here :) > >>> > > >>> > After doing manually regression merges for 9.1 and 9.2 on more than > 50 > >>> > regression tests for each merge, you learn quite a bit... Making it > >>> > more > >>> > painful will just consume more time than necessary. > >>> > > >>> >> On some other thread he seemed ok to extend \d+ > >>> > > >>> > Call that experience, I was OK with with ¥d+ before actually having a > >>> > look > >>> > at the number of tests using it. > >>> > -- > >>> > Michael > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> Free Next-Gen Firewall Hardware Offer > >>> Buy your Sophos next-gen firewall before the end March 2013 > >>> and get the hardware for free! Learn more. > >>> http://p.sf.net/sfu/sophos-d2d-feb > >>> _______________________________________________ > >>> Postgres-xc-developers mailing list > >>> Pos...@li... > >>> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > >> > >> > >> > >> > >> -- > >> Best Wishes, > >> Ashutosh Bapat > >> EntepriseDB Corporation > >> The Enterprise Postgres Company > >> > >> > >> > ------------------------------------------------------------------------------ > >> Free Next-Gen Firewall Hardware Offer > >> Buy your Sophos next-gen firewall before the end March 2013 > >> and get the hardware for free! Learn more. > >> http://p.sf.net/sfu/sophos-d2d-feb > >> _______________________________________________ > >> Postgres-xc-developers mailing list > >> Pos...@li... > >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > >> > > > > > > > ------------------------------------------------------------------------------ > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://p.sf.net/sfu/appdyn_d2d_feb > > _______________________________________________ > > Postgres-xc-developers mailing list > > Pos...@li... > > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > > > > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > Postgres-XC Support and Service > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Postgres-xc-developers mailing list > Pos...@li... > https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Enterprise Postgres Company |
261 messages has been excluded from this view by a project administrator.
