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
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
(14) |
2
|
3
(4) |
4
(12) |
5
(14) |
6
|
|
7
(1) |
8
(7) |
9
(10) |
10
(7) |
11
(8) |
12
(6) |
13
|
|
14
(1) |
15
(3) |
16
(1) |
17
(8) |
18
(11) |
19
(3) |
20
|
|
21
(2) |
22
(9) |
23
(2) |
24
(14) |
25
(13) |
26
(1) |
27
|
|
28
|
29
(1) |
30
(11) |
|
|
|
|
|
From: Abbas B. <abb...@en...> - 2013-04-30 12:30:54
|
On Tue, Apr 30, 2013 at 5:04 PM, Ashutosh Bapat < ash...@en...> wrote: > Hi Abbas, > This change looks confusing. The statements where you have added order by > clause do not correspond to the statements where you have changed the > output. Can you please explain this? > The output of the test cases are changed because there was an error in the expected output files of these test cases. These outputs have to be modified (and the modified output is correct) because of your check in 2608af3d5288607e8245fa10e74e7307bb1bb23d. The order by clause is added in test cases where the expected output was already in order, but results were coming out to be in different order depending on node configuration. > > Also, whenever you change .sql and need to change the .out for that, > please change all the alt. expected output files. > Sure > > > On Thu, Apr 25, 2013 at 4:58 PM, Abbas Butt <abb...@en...>wrote: > >> Hi, >> Attached please find patch to fix test case plpgsql. The test was failing >> for some order by issues, Also there were some errors in expected output. >> >> -- >> *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> |
|
From: Ashutosh B. <ash...@en...> - 2013-04-30 12:09:16
|
Hi Nikhil, We are trying to clean up the regression, so that there are 0 failures. This helps to stop new differences creeping in the already failing files. If there are features we are not supporting in XC, we are silencing those failure (and only those failures) by adding alternate outputs. truncate already has an alternate output file, so you need to change that. On Tue, Apr 30, 2013 at 4:22 PM, Nikhil Sontakke <ni...@st...>wrote: > > > > >> Thanks for the patch. Please include the testcase expected output changes >> as well. >> >> > This patch already has a lot of other issues. I know I can provide a > truncate_1.out but I do not see the point. > > PFA, patch with the documentation fixed up. > > Regards, > Nikhils > > >> >> On Thu, Apr 25, 2013 at 2:21 PM, Nikhil Sontakke <ni...@st...>wrote: >> >>> PFA, the patch to disallow. >>> >>> >>> >> +1 so far. Does anybody know how widely it is used? I hope it is >>> not used widely. >>> >>> Suzuki-san, the user has an option to reset the sequence value >>> afterwards on his own to circumvent this issue. So it should be ok.. >>> >>> Regards, >>> Nikhils >>> >>> >>> >>> On Thu, Apr 25, 2013 at 2:05 PM, Ashutosh Bapat < >>> ash...@en...> wrote: >>> >>>> Can you please provide the patch to restrict the feature? >>>> >>>> >>>> On Thu, Apr 25, 2013 at 2:03 PM, Nikhil Sontakke <ni...@st...>wrote: >>>> >>>>> >>>>> >>>>> If it can not be done easily and before release, we need to at least >>>>>> disable RESTART IDENTITY clause. >>>>>> >>>>>> +1 for now.. >>>>> >>>>> Regards, >>>>> Nikhils >>>>> >>>>> >>>>>> >>>>>> On Wed, Apr 24, 2013 at 11:45 PM, Nikhil Sontakke < >>>>>> ni...@st...> wrote: >>>>>> >>>>>>> Ok, >>>>>>> This is not so straight forward. We cannot reset the sequence value >>>>>>> in the GTM as is. We got to handle the case when the user can rollback the >>>>>>> truncate operation in which case the old value should still hold. >>>>>>> >>>>>>> ISTM, we need to add handing code when the commit operation actually >>>>>>> unlinks the corresponding underlying relfilenode for the earlier version of >>>>>>> the sequence. >>>>>>> >>>>>>> Regards, >>>>>>> Nikhils >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 24, 2013 at 7:34 PM, Ashutosh Bapat < >>>>>>> ash...@en...> wrote: >>>>>>> >>>>>>>> Good, that works. This bug is causing testcase truncate to fail. >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Apr 24, 2013 at 6:53 PM, Nikhil Sontakke < >>>>>>>> ni...@st...> wrote: >>>>>>>> >>>>>>>>> Hi Ashutosh, >>>>>>>>> >>>>>>>>> By the EOW? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Nikhils >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Apr 24, 2013 at 6:49 PM, Ashutosh Bapat < >>>>>>>>> ash...@en...> wrote: >>>>>>>>> >>>>>>>>>> Hi Nikhil, >>>>>>>>>> Thanks for taking this up? >>>>>>>>>> >>>>>>>>>> By when do you think you can provide the patch? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Apr 24, 2013 at 6:01 PM, Nikhil Sontakke < >>>>>>>>>> ni...@st...> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> ResetSequence(), the function being called from >>>>>>>>>>>> ExecuteTruncate() does not send reset message to GTM. It applies sequence >>>>>>>>>>>> changes locally on the coordinator, which is not enough. >>>>>>>>>>>> >>>>>>>>>>>> Can someone with relevant experience look into this problem and >>>>>>>>>>>> provide a fix? >>>>>>>>>>>> >>>>>>>>>>>> I have attached the testcase and its output showing the bug. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> I guess setval() was handled but we forgot to handle reset >>>>>>>>>>> sequence. I will take this up when I cleanup currval, nextval for negative >>>>>>>>>>> sequences. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Nikhils >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Best Wishes, >>>>>>>>>> Ashutosh Bapat >>>>>>>>>> EntepriseDB Corporation >>>>>>>>>> The Postgres Database Company >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> StormDB - http://www.stormdb.com >>>>>>>>> The Database Cloud >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best Wishes, >>>>>>>> Ashutosh Bapat >>>>>>>> EntepriseDB Corporation >>>>>>>> The Postgres Database Company >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> StormDB - http://www.stormdb.com >>>>>>> The Database Cloud >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best Wishes, >>>>>> Ashutosh Bapat >>>>>> EntepriseDB Corporation >>>>>> The Postgres Database Company >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> StormDB - http://www.stormdb.com >>>>> The Database Cloud >>>>> >>>> >>>> >>>> >>>> -- >>>> Best Wishes, >>>> Ashutosh Bapat >>>> EntepriseDB Corporation >>>> The Postgres Database Company >>>> >>> >>> >>> >>> -- >>> StormDB - http://www.stormdb.com >>> The Database Cloud >>> >> >> >> >> -- >> Best Wishes, >> Ashutosh Bapat >> EntepriseDB Corporation >> The Postgres Database Company >> > > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Postgres Database Company |
|
From: Ashutosh B. <ash...@en...> - 2013-04-30 12:05:03
|
Hi Abbas, This change looks confusing. The statements where you have added order by clause do not correspond to the statements where you have changed the output. Can you please explain this? Also, whenever you change .sql and need to change the .out for that, please change all the alt. expected output files. On Thu, Apr 25, 2013 at 4:58 PM, Abbas Butt <abb...@en...>wrote: > Hi, > Attached please find patch to fix test case plpgsql. The test was failing > for some order by issues, Also there were some errors in expected output. > > -- > *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 |
|
From: Ashutosh B. <ash...@en...> - 2013-04-30 11:57:35
|
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. Please make sure that the changes you have done (explain output) reflect in all the alt. expected output files. Can you please see if we can eliminate the alternate expected output files as well? What are the reasons we have to maintain those? 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 |
|
From: Ashutosh B. <ash...@en...> - 2013-04-30 11:19:56
|
Hi Abbas, copy2 has an alternate output file. So, if you change .sql file, you need to make corresponding changes in .out and _1.out. There is one missing change about not enforcing 2PC with temporary tables, which needs to be carried to .out file as well. Otherwise the change looks good. While adding the ORDER BY clause, hope you have made sure that the data that is output is same except for change in the ordering. This testcase needs to be looked at by Amit for the trigger related changes. After that I think we should remove alt. output file. On Wed, Apr 24, 2013 at 10:58 PM, Abbas Butt <abb...@en...>wrote: > Hi, > Test was failing because of some order by issues in COPY TO statements. > > -- > *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 |
|
From: Ashutosh B. <ash...@en...> - 2013-04-30 10:41:49
|
Hi Abbas, Instead of fixing this in GetRelationNodes, we should fix it outside, by calling GetPrefferedNode on the result returned by GetRelationNodes for replicated tables. Please send a revised patch with this change. May be you want to examine all callers of GetRelationNodes. On Wed, Apr 24, 2013 at 10:58 PM, Abbas Butt <abb...@en...>wrote: > Hi, > The test case fails if there is no primary node in the cluster. The > following test case was producing error. > > CREATE TABLE tt_22 (a int, b int) distribute by replication; > INSERT INTO tt_22 VALUES (10); > > In a four datanode cluster the following query plan was being produced. > > explain verbose SELECT * FROM tt_22 FOR UPDATE; > QUERY > PLAN > > ---------------------------------------------------------------------------- > Data Node Scan on "__REMOTE_FQS_QUERY__" (cost=0.00..0.00 rows=0 width=0) > Output: tt_22.a, tt_22.b > Node/s: data_node_1, data_node_2, data_node_3, data_node_4 > Remote query: SELECT a, b FROM tt_22 FOR UPDATE OF tt_22 > (4 rows) > > The reason was a missing else case in GetRelationNodes. > > > -- > *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 |
|
From: Ashutosh B. <ash...@en...> - 2013-04-30 10:22:42
|
Hi Abbas, As discussed on IM, since the test here just tested quoted names, it doesn't need two rows. So, it would suffices removing the second row. However, if the original author is around, it might be better to know why he added two rows and not one row. On Wed, Apr 24, 2013 at 10:56 PM, Abbas Butt <abb...@en...>wrote: > Hi, > The test case was failing because of order by issues in copy. The solution > is to use same data in both inserted rows, since it has nothing to do with > the quoted name test. > > -- > *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 |
|
From: Ashutosh B. <ash...@en...> - 2013-04-30 09:35:01
|
Hi Abbas, I see that you have used create_table_nodes function to create some of the tables. Why not all? As you explained on IM chat, that the tables need to be distributed on given number of nodes only, it's better to distribute them only on two nodes. Please add a comment explaining this. Also, why can't you use int4_tbl and int8_tbl that is default available in the regression. If the content of that table changes, there are many other tests that would fail. There are white space, please check if they are in .sql file or .out file. The ones in .sql file need to be removed. Rest looks fine. On Wed, Apr 24, 2013 at 10:55 PM, Abbas Butt <abb...@en...>wrote: > Hi, > The test cases was failing for a four datanode cluster. The reason was > that some tables were not created on a well defined datanode set. > > -- > *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 |
|
From: Amit K. <ami...@en...> - 2013-04-26 13:09:16
|
In the UPDATE implemention in XC, once we get the source data alongwith ctids, we start updating the records, but we don't issue a row lock, so we can end up updating a totally different row if it is already updated by some other update that happened in between fetching the rows and updating them. And this results in data inconsistency. For an e.g. see here: http://sourceforge.net/tracker/?func=detail&aid=3606317&group_id=311227&atid=1310232 PG acquires an exclusive row lock and gets a revised version of the tuple if the tuple has changed (heap_update), and then again runs the quals to check if this new tuple satisfies the quals. XC does not do this. So another concurrent update happening after the ctid has fetched but before updating the tuple with that ctid can cause data inconsistency. The same happens for DELETE, and also for a BEFORE TRIGGER execution. The row should be locked before doing both of these operations, and the revised version of the tuple should be used. So in case of all the 3 operations above, lock the rows that are to be processed by appending FOR UPDATE in the remote query. If there are coordinator quals, we should run FOR-UPDATE for only those rows that satisfy the quals. Once this is done, we can safely assume that the row is locked when it comes to actual processing of that row (update/delete/trigger), and so skip the "lock-and-fetch-revised-tuple-and-rerun-qual" step that PG does. Consider this query: UPDATE employees SET sales_count = sales_count + 1 FROM accounts WHERE accounts.name = 'Acme' AND employees.empname = f(employees.empname) and employees.id = accounts.sales_person; QUERY PLAN ----------------------------------------------------------------------------------------------------------------------------------------- Update on public.employees Node expr: employees.id Remote query: UPDATE ONLY employees SET sales_count = $3 WHERE ((employees.ctid = $4) AND (employees.xc_node_id = $5)) -> Nested Loop Output: employees.id, NULL::character varying, (employees.sales_count + 1), employees.ctid, employees.xc_node_id, accounts.ctid Join Filter: (employees.id = accounts.sales_person) -> Data Node Scan on *employees* "_REMOTE_TABLE_QUERY_" Output: employees.id, employees.sales_count, employees.ctid, employees.xc_node_id Remote query: SELECT id, sales_count, ctid, xc_node_id, empname FROM ONLY employees WHERE true Coordinator quals: ((employees.empname)::text = (f(employees.empname))::text) -> Data Node Scan on *accounts* "_REMOTE_TABLE_QUERY_" Output: accounts.ctid, accounts.sales_person Remote query: SELECT ctid, sales_person FROM ONLY accounts WHERE ((name)::text = 'Acme'::text) (13 rows) The idea is to make the plan look something like this: QUERY PLAN ----------------------------------------------------------------------------------------------------------------------------------------- Update on public.employees Node expr: employees.id Remote query: UPDATE ONLY employees SET sales_count = $3 WHERE ((employees.ctid = $4) AND (employees.xc_node_id = $5)) -> Nested Loop Output: employees.id, NULL::character varying, (employees.sales_count + 1), employees.ctid, employees.xc_node_id, accounts.ctid Join Filter: (employees.id = accounts.sales_person) -> Data Node Scan on *employees* "_REMOTE_TABLE_QUERY_" (*Or some different node type)* Output: employees.id, employees.sales_count, employees.ctid, employees.xc_node_id, employees.* Remote query: SELECT id, sales_count, ctid, xc_node_id, employees.* FROM ONLY employees *WHERE employees.ctid IN ($1) FOR UPDATE* *OF employees* -> Data Node Scan on employees "_REMOTE_TABLE_QUERY_" Output: employees.ctid, employees.xc_node_id Remote query: SELECT *ctid, xc_node_id*, empname FROM ONLY employees WHERE true Coordinator quals: ((employees.empname)::text = (f(employees.empname))::text) -> Data Node Scan on *accounts* "_REMOTE_TABLE_QUERY_" Output: accounts.ctid, accounts.sales_person Remote query: SELECT ctid, sales_person FROM ONLY accounts WHERE ((name)::text = 'Acme'::text) (13 rows) In the above hypothetical plan, the upper RemoteQuery node has a subnode that fetches only ctid/xc_node_id. The results are collected and input to the $1 parameter for the parent node for the IN clause. The upper RemoteQuery node (or some new type of node) on the first execution will have to do special processing : it will run ExecProcNode() multiple times until it fetches all the ctids from the child node. And then for subsequent execution, keep returning the fetched tuples. The situation complicates further because all the ctids should belong to the same node_id. So it needs to do this cycle for each of the nodes, which means it should group the collected ctids according to which node_id they belong. All this would happen transparently to the caller of this RemoteQuery node. In the above plan, the Nested Loop node would get the rows from employees as usual, but effectively they would be locked. Instead of *ctid IN ($1) *if we use *ctid = ($1), *it means the upper node will not do batch processing, it will retrieve the lower node ctids one by one and return the SELECT FOR UPDATE row for this ctid to the caller; that is, the upper RemoteQuery node would not have to do any special processing. But obviously it is slower. Will check how involved it gets with *ctid in ($1)*. create_remotequery_plan() function itself would create a subnode and save it in its lefttree. This parent node will be marked as read-only=false or something else which will indicate to the combiner that primary node should be used to serialize the FOR-UPDATE locking. Comments and suggestions welcome. Thanks -Amit |
|
From: Abbas B. <abb...@en...> - 2013-04-25 11:28:22
|
Hi, Attached please find patch to fix test case plpgsql. The test was failing for some order by issues, Also there were some errors in expected output. -- *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-04-25 10:46:31
|
And yes, the documentation changes as well. On Thu, Apr 25, 2013 at 2:24 PM, Ashutosh Bapat < ash...@en...> wrote: > Hi Nikhil, > Thanks for the patch. Please include the testcase expected output changes > as well. > > > On Thu, Apr 25, 2013 at 2:21 PM, Nikhil Sontakke <ni...@st...>wrote: > >> PFA, the patch to disallow. >> >> >> >> +1 so far. Does anybody know how widely it is used? I hope it is >> not used widely. >> >> Suzuki-san, the user has an option to reset the sequence value afterwards >> on his own to circumvent this issue. So it should be ok.. >> >> Regards, >> Nikhils >> >> >> >> On Thu, Apr 25, 2013 at 2:05 PM, Ashutosh Bapat < >> ash...@en...> wrote: >> >>> Can you please provide the patch to restrict the feature? >>> >>> >>> On Thu, Apr 25, 2013 at 2:03 PM, Nikhil Sontakke <ni...@st...>wrote: >>> >>>> >>>> >>>> If it can not be done easily and before release, we need to at least >>>>> disable RESTART IDENTITY clause. >>>>> >>>>> +1 for now.. >>>> >>>> Regards, >>>> Nikhils >>>> >>>> >>>>> >>>>> On Wed, Apr 24, 2013 at 11:45 PM, Nikhil Sontakke <ni...@st... >>>>> > wrote: >>>>> >>>>>> Ok, >>>>>> This is not so straight forward. We cannot reset the sequence value >>>>>> in the GTM as is. We got to handle the case when the user can rollback the >>>>>> truncate operation in which case the old value should still hold. >>>>>> >>>>>> ISTM, we need to add handing code when the commit operation actually >>>>>> unlinks the corresponding underlying relfilenode for the earlier version of >>>>>> the sequence. >>>>>> >>>>>> Regards, >>>>>> Nikhils >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Apr 24, 2013 at 7:34 PM, Ashutosh Bapat < >>>>>> ash...@en...> wrote: >>>>>> >>>>>>> Good, that works. This bug is causing testcase truncate to fail. >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 24, 2013 at 6:53 PM, Nikhil Sontakke < >>>>>>> ni...@st...> wrote: >>>>>>> >>>>>>>> Hi Ashutosh, >>>>>>>> >>>>>>>> By the EOW? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Nikhils >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Apr 24, 2013 at 6:49 PM, Ashutosh Bapat < >>>>>>>> ash...@en...> wrote: >>>>>>>> >>>>>>>>> Hi Nikhil, >>>>>>>>> Thanks for taking this up? >>>>>>>>> >>>>>>>>> By when do you think you can provide the patch? >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Apr 24, 2013 at 6:01 PM, Nikhil Sontakke < >>>>>>>>> ni...@st...> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> ResetSequence(), the function being called from >>>>>>>>>>> ExecuteTruncate() does not send reset message to GTM. It applies sequence >>>>>>>>>>> changes locally on the coordinator, which is not enough. >>>>>>>>>>> >>>>>>>>>>> Can someone with relevant experience look into this problem and >>>>>>>>>>> provide a fix? >>>>>>>>>>> >>>>>>>>>>> I have attached the testcase and its output showing the bug. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I guess setval() was handled but we forgot to handle reset >>>>>>>>>> sequence. I will take this up when I cleanup currval, nextval for negative >>>>>>>>>> sequences. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Nikhils >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Best Wishes, >>>>>>>>> Ashutosh Bapat >>>>>>>>> EntepriseDB Corporation >>>>>>>>> The Postgres Database Company >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> StormDB - http://www.stormdb.com >>>>>>>> The Database Cloud >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Best Wishes, >>>>>>> Ashutosh Bapat >>>>>>> EntepriseDB Corporation >>>>>>> The Postgres Database Company >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> StormDB - http://www.stormdb.com >>>>>> The Database Cloud >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best Wishes, >>>>> Ashutosh Bapat >>>>> EntepriseDB Corporation >>>>> The Postgres Database Company >>>>> >>>> >>>> >>>> >>>> -- >>>> StormDB - http://www.stormdb.com >>>> The Database Cloud >>>> >>> >>> >>> >>> -- >>> Best Wishes, >>> Ashutosh Bapat >>> EntepriseDB Corporation >>> The Postgres Database Company >>> >> >> >> >> -- >> StormDB - http://www.stormdb.com >> The Database Cloud >> > > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Postgres Database Company > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Postgres Database Company |
|
From: Ashutosh B. <ash...@en...> - 2013-04-25 10:16:00
|
Thanks Abbas for quick review. I will take care of inherit and truncate. I am committing this patch. On Thu, Apr 25, 2013 at 3:44 PM, Abbas Butt <abb...@en...>wrote: > The patch fixes the attached test case as well as the one that was failing > in plpgsql.sql. > > Regression before and after the patch shows some diffs in the following > files > > 1. plpgsql - I will take care of those > 2. truncate & > 3. Inherit > > I have attached the regression.diff before and after the patch. > > The patch can be committed , the additional diffs can be taken care of > separately. > > Regards > > > On Wed, Apr 24, 2013 at 3:27 PM, Ashutosh Bapat < > ash...@en...> wrote: > >> Hi All, >> PFA a patch to fix the cached plan and aggregate problem. Attached is the >> test code which gave wrong answer. >> >> >> PLpgSQL functions create plans for the queries involved in the functions >> and cache those. While caching the plan for these queries is copied using >> copyObject function, which in turn calls _copyAgg for copying the aggregate >> nodes in the plan. _copyAgg was not copying the skip_trans status, which >> caused the transitioned results from datanodes to be transitioned again. >> Hence we got wrong answer for count(*) aggregate. >> >> The bug was uncovered from testcase truncate. Someone had just copied the >> wrong results in alternate expected output file. >> >> -- >> Best Wishes, >> Ashutosh Bapat >> EntepriseDB Corporation >> The Postgres Database Company >> >> >> ------------------------------------------------------------------------------ >> 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 >> >> > > > -- > -- > *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 |
|
From: Ashutosh B. <ash...@en...> - 2013-04-25 08:54:59
|
Hi Nikhil, Thanks for the patch. Please include the testcase expected output changes as well. On Thu, Apr 25, 2013 at 2:21 PM, Nikhil Sontakke <ni...@st...>wrote: > PFA, the patch to disallow. > > > >> +1 so far. Does anybody know how widely it is used? I hope it is > not used widely. > > Suzuki-san, the user has an option to reset the sequence value afterwards > on his own to circumvent this issue. So it should be ok.. > > Regards, > Nikhils > > > > On Thu, Apr 25, 2013 at 2:05 PM, Ashutosh Bapat < > ash...@en...> wrote: > >> Can you please provide the patch to restrict the feature? >> >> >> On Thu, Apr 25, 2013 at 2:03 PM, Nikhil Sontakke <ni...@st...>wrote: >> >>> >>> >>> If it can not be done easily and before release, we need to at least >>>> disable RESTART IDENTITY clause. >>>> >>>> +1 for now.. >>> >>> Regards, >>> Nikhils >>> >>> >>>> >>>> On Wed, Apr 24, 2013 at 11:45 PM, Nikhil Sontakke <ni...@st...>wrote: >>>> >>>>> Ok, >>>>> This is not so straight forward. We cannot reset the sequence value in >>>>> the GTM as is. We got to handle the case when the user can rollback the >>>>> truncate operation in which case the old value should still hold. >>>>> >>>>> ISTM, we need to add handing code when the commit operation actually >>>>> unlinks the corresponding underlying relfilenode for the earlier version of >>>>> the sequence. >>>>> >>>>> Regards, >>>>> Nikhils >>>>> >>>>> >>>>> >>>>> On Wed, Apr 24, 2013 at 7:34 PM, Ashutosh Bapat < >>>>> ash...@en...> wrote: >>>>> >>>>>> Good, that works. This bug is causing testcase truncate to fail. >>>>>> >>>>>> >>>>>> On Wed, Apr 24, 2013 at 6:53 PM, Nikhil Sontakke <ni...@st... >>>>>> > wrote: >>>>>> >>>>>>> Hi Ashutosh, >>>>>>> >>>>>>> By the EOW? >>>>>>> >>>>>>> Regards, >>>>>>> Nikhils >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 24, 2013 at 6:49 PM, Ashutosh Bapat < >>>>>>> ash...@en...> wrote: >>>>>>> >>>>>>>> Hi Nikhil, >>>>>>>> Thanks for taking this up? >>>>>>>> >>>>>>>> By when do you think you can provide the patch? >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Apr 24, 2013 at 6:01 PM, Nikhil Sontakke < >>>>>>>> ni...@st...> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> ResetSequence(), the function being called from ExecuteTruncate() >>>>>>>>>> does not send reset message to GTM. It applies sequence changes locally on >>>>>>>>>> the coordinator, which is not enough. >>>>>>>>>> >>>>>>>>>> Can someone with relevant experience look into this problem and >>>>>>>>>> provide a fix? >>>>>>>>>> >>>>>>>>>> I have attached the testcase and its output showing the bug. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I guess setval() was handled but we forgot to handle reset >>>>>>>>> sequence. I will take this up when I cleanup currval, nextval for negative >>>>>>>>> sequences. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Nikhils >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Best Wishes, >>>>>>>> Ashutosh Bapat >>>>>>>> EntepriseDB Corporation >>>>>>>> The Postgres Database Company >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> StormDB - http://www.stormdb.com >>>>>>> The Database Cloud >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best Wishes, >>>>>> Ashutosh Bapat >>>>>> EntepriseDB Corporation >>>>>> The Postgres Database Company >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> StormDB - http://www.stormdb.com >>>>> The Database Cloud >>>>> >>>> >>>> >>>> >>>> -- >>>> Best Wishes, >>>> Ashutosh Bapat >>>> EntepriseDB Corporation >>>> The Postgres Database Company >>>> >>> >>> >>> >>> -- >>> StormDB - http://www.stormdb.com >>> The Database Cloud >>> >> >> >> >> -- >> Best Wishes, >> Ashutosh Bapat >> EntepriseDB Corporation >> The Postgres Database Company >> > > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Postgres Database Company |
|
From: 鈴木 幸市 <ko...@in...> - 2013-04-25 08:46:05
|
+1 so far. Does anybody know how widely it is used? I hope it is not used widely. --- Koichi Suzuki On 2013/04/25, at 17:35, Ashutosh Bapat <ash...@en...> wrote: > Can you please provide the patch to restrict the feature? > > > On Thu, Apr 25, 2013 at 2:03 PM, Nikhil Sontakke <ni...@st...> wrote: > > > If it can not be done easily and before release, we need to at least disable RESTART IDENTITY clause. > > +1 for now.. > > Regards, > Nikhils > > > On Wed, Apr 24, 2013 at 11:45 PM, Nikhil Sontakke <ni...@st...> wrote: > Ok, > This is not so straight forward. We cannot reset the sequence value in the GTM as is. We got to handle the case when the user can rollback the truncate operation in which case the old value should still hold. > > ISTM, we need to add handing code when the commit operation actually unlinks the corresponding underlying relfilenode for the earlier version of the sequence. > > Regards, > Nikhils > > > > On Wed, Apr 24, 2013 at 7:34 PM, Ashutosh Bapat <ash...@en...> wrote: > Good, that works. This bug is causing testcase truncate to fail. > > > On Wed, Apr 24, 2013 at 6:53 PM, Nikhil Sontakke <ni...@st...> wrote: > Hi Ashutosh, > > By the EOW? > > Regards, > Nikhils > > > > On Wed, Apr 24, 2013 at 6:49 PM, Ashutosh Bapat <ash...@en...> wrote: > Hi Nikhil, > Thanks for taking this up? > > By when do you think you can provide the patch? > > > On Wed, Apr 24, 2013 at 6:01 PM, Nikhil Sontakke <ni...@st...> wrote: > > > > ResetSequence(), the function being called from ExecuteTruncate() does not send reset message to GTM. It applies sequence changes locally on the coordinator, which is not enough. > > Can someone with relevant experience look into this problem and provide a fix? > > I have attached the testcase and its output showing the bug. > > > I guess setval() was handled but we forgot to handle reset sequence. I will take this up when I cleanup currval, nextval for negative sequences. > > Regards, > Nikhils > > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Postgres Database Company > > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Postgres Database Company > > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Postgres Database Company > > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Postgres Database Company > ------------------------------------------------------------------------------ > 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 |
|
From: Ashutosh B. <ash...@en...> - 2013-04-25 08:35:19
|
Can you please provide the patch to restrict the feature? On Thu, Apr 25, 2013 at 2:03 PM, Nikhil Sontakke <ni...@st...>wrote: > > > If it can not be done easily and before release, we need to at least >> disable RESTART IDENTITY clause. >> >> +1 for now.. > > Regards, > Nikhils > > >> >> On Wed, Apr 24, 2013 at 11:45 PM, Nikhil Sontakke <ni...@st...>wrote: >> >>> Ok, >>> This is not so straight forward. We cannot reset the sequence value in >>> the GTM as is. We got to handle the case when the user can rollback the >>> truncate operation in which case the old value should still hold. >>> >>> ISTM, we need to add handing code when the commit operation actually >>> unlinks the corresponding underlying relfilenode for the earlier version of >>> the sequence. >>> >>> Regards, >>> Nikhils >>> >>> >>> >>> On Wed, Apr 24, 2013 at 7:34 PM, Ashutosh Bapat < >>> ash...@en...> wrote: >>> >>>> Good, that works. This bug is causing testcase truncate to fail. >>>> >>>> >>>> On Wed, Apr 24, 2013 at 6:53 PM, Nikhil Sontakke <ni...@st...>wrote: >>>> >>>>> Hi Ashutosh, >>>>> >>>>> By the EOW? >>>>> >>>>> Regards, >>>>> Nikhils >>>>> >>>>> >>>>> >>>>> On Wed, Apr 24, 2013 at 6:49 PM, Ashutosh Bapat < >>>>> ash...@en...> wrote: >>>>> >>>>>> Hi Nikhil, >>>>>> Thanks for taking this up? >>>>>> >>>>>> By when do you think you can provide the patch? >>>>>> >>>>>> >>>>>> On Wed, Apr 24, 2013 at 6:01 PM, Nikhil Sontakke <ni...@st... >>>>>> > wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> ResetSequence(), the function being called from ExecuteTruncate() >>>>>>>> does not send reset message to GTM. It applies sequence changes locally on >>>>>>>> the coordinator, which is not enough. >>>>>>>> >>>>>>>> Can someone with relevant experience look into this problem and >>>>>>>> provide a fix? >>>>>>>> >>>>>>>> I have attached the testcase and its output showing the bug. >>>>>>>> >>>>>>>> >>>>>>> I guess setval() was handled but we forgot to handle reset sequence. >>>>>>> I will take this up when I cleanup currval, nextval for negative sequences. >>>>>>> >>>>>>> Regards, >>>>>>> Nikhils >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best Wishes, >>>>>> Ashutosh Bapat >>>>>> EntepriseDB Corporation >>>>>> The Postgres Database Company >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> StormDB - http://www.stormdb.com >>>>> The Database Cloud >>>>> >>>> >>>> >>>> >>>> -- >>>> Best Wishes, >>>> Ashutosh Bapat >>>> EntepriseDB Corporation >>>> The Postgres Database Company >>>> >>> >>> >>> >>> -- >>> StormDB - http://www.stormdb.com >>> The Database Cloud >>> >> >> >> >> -- >> Best Wishes, >> Ashutosh Bapat >> EntepriseDB Corporation >> The Postgres Database Company >> > > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Postgres Database Company |
|
From: Nikhil S. <ni...@st...> - 2013-04-25 08:34:10
|
If it can not be done easily and before release, we need to at least > disable RESTART IDENTITY clause. > > +1 for now.. Regards, Nikhils > > On Wed, Apr 24, 2013 at 11:45 PM, Nikhil Sontakke <ni...@st...>wrote: > >> Ok, >> This is not so straight forward. We cannot reset the sequence value in >> the GTM as is. We got to handle the case when the user can rollback the >> truncate operation in which case the old value should still hold. >> >> ISTM, we need to add handing code when the commit operation actually >> unlinks the corresponding underlying relfilenode for the earlier version of >> the sequence. >> >> Regards, >> Nikhils >> >> >> >> On Wed, Apr 24, 2013 at 7:34 PM, Ashutosh Bapat < >> ash...@en...> wrote: >> >>> Good, that works. This bug is causing testcase truncate to fail. >>> >>> >>> On Wed, Apr 24, 2013 at 6:53 PM, Nikhil Sontakke <ni...@st...>wrote: >>> >>>> Hi Ashutosh, >>>> >>>> By the EOW? >>>> >>>> Regards, >>>> Nikhils >>>> >>>> >>>> >>>> On Wed, Apr 24, 2013 at 6:49 PM, Ashutosh Bapat < >>>> ash...@en...> wrote: >>>> >>>>> Hi Nikhil, >>>>> Thanks for taking this up? >>>>> >>>>> By when do you think you can provide the patch? >>>>> >>>>> >>>>> On Wed, Apr 24, 2013 at 6:01 PM, Nikhil Sontakke <ni...@st...>wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> ResetSequence(), the function being called from ExecuteTruncate() >>>>>>> does not send reset message to GTM. It applies sequence changes locally on >>>>>>> the coordinator, which is not enough. >>>>>>> >>>>>>> Can someone with relevant experience look into this problem and >>>>>>> provide a fix? >>>>>>> >>>>>>> I have attached the testcase and its output showing the bug. >>>>>>> >>>>>>> >>>>>> I guess setval() was handled but we forgot to handle reset sequence. >>>>>> I will take this up when I cleanup currval, nextval for negative sequences. >>>>>> >>>>>> Regards, >>>>>> Nikhils >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best Wishes, >>>>> Ashutosh Bapat >>>>> EntepriseDB Corporation >>>>> The Postgres Database Company >>>>> >>>> >>>> >>>> >>>> -- >>>> StormDB - http://www.stormdb.com >>>> The Database Cloud >>>> >>> >>> >>> >>> -- >>> Best Wishes, >>> Ashutosh Bapat >>> EntepriseDB Corporation >>> The Postgres Database Company >>> >> >> >> >> -- >> StormDB - http://www.stormdb.com >> The Database Cloud >> > > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Postgres Database Company > -- StormDB - http://www.stormdb.com The Database Cloud |
|
From: Koichi S. <koi...@gm...> - 2013-04-25 06:24:29
|
Hello, Now REL1_1_STABLE branch is available for next major version up development both in sourceforge and github. This includes all the commits of PostgreSQL REL9_2_STABLE. Regards; ---------- Koichi Suzuki |
|
From: 鈴木 幸市 <ko...@in...> - 2013-04-25 06:16:29
|
I understand it's not simple when such operation should handle abort. GTM may need some cleanups to handle transaction recovery. --- Koichi Suzuki On 2013/04/25, at 12:24, Ashutosh Bapat <ash...@en...> wrote: > If it can not be done easily and before release, we need to at least disable RESTART IDENTITY clause. > > > On Wed, Apr 24, 2013 at 11:45 PM, Nikhil Sontakke <ni...@st...> wrote: > Ok, > This is not so straight forward. We cannot reset the sequence value in the GTM as is. We got to handle the case when the user can rollback the truncate operation in which case the old value should still hold. > > ISTM, we need to add handing code when the commit operation actually unlinks the corresponding underlying relfilenode for the earlier version of the sequence. > > Regards, > Nikhils > > > > On Wed, Apr 24, 2013 at 7:34 PM, Ashutosh Bapat <ash...@en...> wrote: > Good, that works. This bug is causing testcase truncate to fail. > > > On Wed, Apr 24, 2013 at 6:53 PM, Nikhil Sontakke <ni...@st...> wrote: > Hi Ashutosh, > > By the EOW? > > Regards, > Nikhils > > > > On Wed, Apr 24, 2013 at 6:49 PM, Ashutosh Bapat <ash...@en...> wrote: > Hi Nikhil, > Thanks for taking this up? > > By when do you think you can provide the patch? > > > On Wed, Apr 24, 2013 at 6:01 PM, Nikhil Sontakke <ni...@st...> wrote: > > > > ResetSequence(), the function being called from ExecuteTruncate() does not send reset message to GTM. It applies sequence changes locally on the coordinator, which is not enough. > > Can someone with relevant experience look into this problem and provide a fix? > > I have attached the testcase and its output showing the bug. > > > I guess setval() was handled but we forgot to handle reset sequence. I will take this up when I cleanup currval, nextval for negative sequences. > > Regards, > Nikhils > > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Postgres Database Company > > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Postgres Database Company > > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Postgres Database Company > ------------------------------------------------------------------------------ > 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 |
|
From: Ashutosh B. <ash...@en...> - 2013-04-25 03:24:54
|
If it can not be done easily and before release, we need to at least disable RESTART IDENTITY clause. On Wed, Apr 24, 2013 at 11:45 PM, Nikhil Sontakke <ni...@st...>wrote: > Ok, > This is not so straight forward. We cannot reset the sequence value in the > GTM as is. We got to handle the case when the user can rollback the > truncate operation in which case the old value should still hold. > > ISTM, we need to add handing code when the commit operation actually > unlinks the corresponding underlying relfilenode for the earlier version of > the sequence. > > Regards, > Nikhils > > > > On Wed, Apr 24, 2013 at 7:34 PM, Ashutosh Bapat < > ash...@en...> wrote: > >> Good, that works. This bug is causing testcase truncate to fail. >> >> >> On Wed, Apr 24, 2013 at 6:53 PM, Nikhil Sontakke <ni...@st...>wrote: >> >>> Hi Ashutosh, >>> >>> By the EOW? >>> >>> Regards, >>> Nikhils >>> >>> >>> >>> On Wed, Apr 24, 2013 at 6:49 PM, Ashutosh Bapat < >>> ash...@en...> wrote: >>> >>>> Hi Nikhil, >>>> Thanks for taking this up? >>>> >>>> By when do you think you can provide the patch? >>>> >>>> >>>> On Wed, Apr 24, 2013 at 6:01 PM, Nikhil Sontakke <ni...@st...>wrote: >>>> >>>>> >>>>> >>>>> >>>>> >>>>>> ResetSequence(), the function being called from ExecuteTruncate() >>>>>> does not send reset message to GTM. It applies sequence changes locally on >>>>>> the coordinator, which is not enough. >>>>>> >>>>>> Can someone with relevant experience look into this problem and >>>>>> provide a fix? >>>>>> >>>>>> I have attached the testcase and its output showing the bug. >>>>>> >>>>>> >>>>> I guess setval() was handled but we forgot to handle reset sequence. I >>>>> will take this up when I cleanup currval, nextval for negative sequences. >>>>> >>>>> Regards, >>>>> Nikhils >>>>> >>>> >>>> >>>> >>>> -- >>>> Best Wishes, >>>> Ashutosh Bapat >>>> EntepriseDB Corporation >>>> The Postgres Database Company >>>> >>> >>> >>> >>> -- >>> StormDB - http://www.stormdb.com >>> The Database Cloud >>> >> >> >> >> -- >> Best Wishes, >> Ashutosh Bapat >> EntepriseDB Corporation >> The Postgres Database Company >> > > > > -- > StormDB - http://www.stormdb.com > The Database Cloud > -- Best Wishes, Ashutosh Bapat EntepriseDB Corporation The Postgres Database Company |
|
From: Nikhil S. <ni...@st...> - 2013-04-24 18:16:00
|
Ok, This is not so straight forward. We cannot reset the sequence value in the GTM as is. We got to handle the case when the user can rollback the truncate operation in which case the old value should still hold. ISTM, we need to add handing code when the commit operation actually unlinks the corresponding underlying relfilenode for the earlier version of the sequence. Regards, Nikhils On Wed, Apr 24, 2013 at 7:34 PM, Ashutosh Bapat < ash...@en...> wrote: > Good, that works. This bug is causing testcase truncate to fail. > > > On Wed, Apr 24, 2013 at 6:53 PM, Nikhil Sontakke <ni...@st...>wrote: > >> Hi Ashutosh, >> >> By the EOW? >> >> Regards, >> Nikhils >> >> >> >> On Wed, Apr 24, 2013 at 6:49 PM, Ashutosh Bapat < >> ash...@en...> wrote: >> >>> Hi Nikhil, >>> Thanks for taking this up? >>> >>> By when do you think you can provide the patch? >>> >>> >>> On Wed, Apr 24, 2013 at 6:01 PM, Nikhil Sontakke <ni...@st...>wrote: >>> >>>> >>>> >>>> >>>> >>>>> ResetSequence(), the function being called from ExecuteTruncate() does >>>>> not send reset message to GTM. It applies sequence changes locally on the >>>>> coordinator, which is not enough. >>>>> >>>>> Can someone with relevant experience look into this problem and >>>>> provide a fix? >>>>> >>>>> I have attached the testcase and its output showing the bug. >>>>> >>>>> >>>> I guess setval() was handled but we forgot to handle reset sequence. I >>>> will take this up when I cleanup currval, nextval for negative sequences. >>>> >>>> Regards, >>>> Nikhils >>>> >>> >>> >>> >>> -- >>> Best Wishes, >>> Ashutosh Bapat >>> EntepriseDB Corporation >>> The Postgres Database Company >>> >> >> >> >> -- >> StormDB - http://www.stormdb.com >> The Database Cloud >> > > > > -- > Best Wishes, > Ashutosh Bapat > EntepriseDB Corporation > The Postgres Database Company > -- StormDB - http://www.stormdb.com The Database Cloud |
|
From: Abbas B. <abb...@en...> - 2013-04-24 17:42:11
|
Hi, The test was failing because ctid was being selected and was not being reset explicitly. SAVEPOINT is not implemented yet and the transaction fails because of that statement. Due to the failure / rollback the ctid remains incremented and that incremented value is dependent on cluster configuration. The solution is to explicitly reset ctid using truncate statement. -- *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-04-24 17:29:16
|
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> |
|
From: Abbas B. <abb...@en...> - 2013-04-24 17:28:47
|
Hi, Test was failing because of some order by issues in COPY TO statements. -- *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-04-24 17:28:08
|
Hi,
The test case fails if there is no primary node in the cluster. The
following test case was producing error.
CREATE TABLE tt_22 (a int, b int) distribute by replication;
INSERT INTO tt_22 VALUES (10);
In a four datanode cluster the following query plan was being produced.
explain verbose SELECT * FROM tt_22 FOR UPDATE;
QUERY PLAN
----------------------------------------------------------------------------
Data Node Scan on "__REMOTE_FQS_QUERY__" (cost=0.00..0.00 rows=0 width=0)
Output: tt_22.a, tt_22.b
Node/s: data_node_1, data_node_2, data_node_3, data_node_4
Remote query: SELECT a, b FROM tt_22 FOR UPDATE OF tt_22
(4 rows)
The reason was a missing else case in GetRelationNodes.
--
*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-04-24 17:26:47
|
Hi, The test case was failing because of order by issues in copy. The solution is to use same data in both inserted rows, since it has nothing to do with the quoted name test. -- *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> |
16 messages has been excluded from this view by a project administrator.
