Menu
▾
▴
Re: [Postgres-xc-developers] Patch to fix a crash in COPY TO from a replicated table [Bug ID 3608374]
|
From: Abbas B. <abb...@en...> - 2013-06-24 11:01:15
|
Hi, Thanks for the review. Here is the updated patch that contains reduced test cases. Also I have updated code comments. The statement failing is already in the comments. Regards On Mon, Jun 17, 2013 at 12:36 PM, Ashutosh Bapat < ash...@en...> wrote: > Hi Abbas, > I think the patch for this is in the other thread (11_fix ..). I looked at > the patch. Here are the comments > 1. There are just too many tests in the patch, without much difference. > Please add only the tests which are needed, and also add comments about the > purpose of the statements. Considering the time at hand, I don't think I > can review all of the tests, so it would be good if it can be reduced to a > minimal set. > 2. The code is fine, but the comment need not have specific details of the > statement failing. Getting preferred node is general practice everywhere > and not just this portion of the code. By the way, we are not getting "just > first node" from the node list but we try to get the preferred node. > > > On Wed, Mar 27, 2013 at 3:55 PM, Abbas Butt <abb...@en...>wrote: > >> Bug ID 3608374 >> >> On Fri, Mar 8, 2013 at 12:25 PM, Abbas Butt <abb...@en...>wrote: >> >>> Attached please find revised patch that provides the following in >>> addition to what it did earlier. >>> >>> 1. Uses GetPreferredReplicationNode() instead of list_truncate() >>> 2. Adds test cases to xc_alter_table and xc_copy. >>> >>> I tested the following in reasonable detail to find whether any other >>> caller of GetRelationNodes() needs some fixing or not and found that none >>> of the other callers needs any more fixing. >>> I tested >>> a) copy >>> b) alter table redistribute >>> c) utilities >>> d) dmls etc >>> >>> However while testing ALTER TABLE, I found that replicated to hash is >>> not working correctly. >>> >>> This test case fails, since only SIX rows are expected in the final >>> result. >>> >>> test=# create table t_r_n12(a int, b int) distribute by replication to >>> node (DATA_NODE_1, DATA_NODE_2); >>> CREATE TABLE >>> test=# insert into t_r_n12 values(1,777),(3,4),(5,6),(20,30),(NULL,999), >>> (NULL, 999); >>> INSERT 0 6 >>> test=# -- rep to hash >>> test=# ALTER TABLE t_r_n12 distribute by hash(a); >>> ALTER TABLE >>> test=# SELECT * FROM t_r_n12 order by 1; >>> a | b >>> ----+----- >>> 1 | 777 >>> 3 | 4 >>> 5 | 6 >>> 20 | 30 >>> | 999 >>> | 999 >>> | 999 >>> | 999 >>> (8 rows) >>> >>> test=# drop table t_r_n12; >>> DROP TABLE >>> >>> I have added a source forge bug tracker id to this case (Artifact >>> 3607290<https://sourceforge.net/tracker/?func=detail&aid=3607290&group_id=311227&atid=1310232>). >>> The reason for this error is that the function distrib_delete_hash does not >>> take into account that the distribution column can be null. I will provide >>> a separate fix for that one. >>> Regression shows no extra failure except that test case xc_alter_table >>> would fail until 3607290 is fixed. >>> >>> Regards >>> >>> >>> >>> On Mon, Feb 25, 2013 at 10:18 AM, Ashutosh Bapat < >>> ash...@en...> wrote: >>> >>>> Thanks a lot Abbas for this quick fix. >>>> >>>> I am sorry, it's caused by my refactoring of GetRelationNodes(). >>>> >>>> If possible, can you please examine the other callers of >>>> GetRelationNodes() which would face the problems, esp. the ones for DML and >>>> utilities. This is other instance, where deciding the nodes to execute on >>>> at the time of execution will help. >>>> >>>> About the fix >>>> Can you please use GetPreferredReplicationNode() instead of >>>> list_truncate()? It will pick the preferred node instead of first one. If >>>> you find more places where we need this fix, it might be better to create a >>>> wrapper function and use it at those places. >>>> >>>> On Sat, Feb 23, 2013 at 2:59 PM, Abbas Butt < >>>> abb...@en...> wrote: >>>> >>>>> 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. >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> 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 >>>> >>> >>> >>> >>> -- >>> -- >>> 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. >>> >> >> >> >> -- >> -- >> 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. > > > > > -- > 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> |
