Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ensJh-0008S5-Lt for pgsql-hackers@arkaria.postgresql.org; Mon, 19 Feb 2018 20:45:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ensJf-0005Ei-Kb for pgsql-hackers@arkaria.postgresql.org; Mon, 19 Feb 2018 20:45:39 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1ensJf-0005EY-A4 for pgsql-hackers@lists.postgresql.org; Mon, 19 Feb 2018 20:45:39 +0000 Received: from smtprelay0212.b.hostedemail.com ([64.98.42.212] helo=smtprelay.b.hostedemail.com) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ensJb-0000cI-OU for pgsql-hackers@postgresql.org; Mon, 19 Feb 2018 20:45:37 +0000 Received: from filter.hostedemail.com (10.5.19.248.rfc1918.com [10.5.19.248]) by smtprelay02.b.hostedemail.com (Postfix) with ESMTP id 5CF71D39AC; Mon, 19 Feb 2018 20:45:34 +0000 (UTC) X-Session-Marker: 616C76686572726540616C76682E6E6F2D69702E6F7267 X-Spam-Summary: 90,0,0,,d41d8cd98f00b204,alvherre@alvh.no-ip.org,:::::::::,RULES_HIT:41:355:379:599:967:973:988:989:1260:1277:1311:1312:1313:1314:1345:1359:1437:1515:1516:1518:1519:1534:1542:1593:1594:1595:1596:1711:1730:1747:1777:1792:2198:2199:2393:2525:2560:2563:2682:2685:2692:2828:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4605:5007:6119:6261:7809:7903:9025:9121:10004:10400:10848:11232:11658:11914:12296:13439:13894:13895:14093:14097:21080:21324:21433:21627:21740:30012:30029:30045:30054:30070,0,RBL:179.57.113.18:@alvh.no-ip.org:.lbl8.mailshell.net-62.8.63.190 64.201.201.201,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:no-ip.org-dnsbl7.mailshell.net-127.4.0.190,Custom_rules:0:0:0,LFtime:75,LUA_SUMMARY:none X-HE-Tag: foot31_136fc2d78292b X-Filterd-Recvd-Size: 3093 Received: from alvin.alvh.no-ip.org (unknown [179.57.113.18]) (Authenticated sender: alvherre@alvh.no-ip.org) by omf02.b.hostedemail.com (Postfix) with ESMTPA; Mon, 19 Feb 2018 20:45:33 +0000 (UTC) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id 4D65171B; Mon, 19 Feb 2018 17:45:31 -0300 (-03) Date: Mon, 19 Feb 2018 17:45:31 -0300 From: Alvaro Herrera To: Peter Eisentraut , Jaime Casanova Cc: Jesper Pedersen , Amit Langote , Pg Hackers Subject: Re: unique indexes on partitioned tables Message-ID: <20180219204531.tsblwxwtz332pp7e@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180219185430.bztdubmwhlceu6xs@alvherre.pgsql> User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I pushed this now, with fixes for the last few comments there were. Peter Eisentraut wrote: > I don't understand the variable name "third". I don't see a "first" or > "second" nearby. Hah. That was referring to variables "myself" and "referenced". I changed the variable name to "parentConstr". > I find some of the columns in pg_constraint confusing. For a primary > key on a partitioned table, for the PK on the partition I get > > conislocal = false, coninhcount = 1, connoinherit = true > > The last part is confusing to me. Yeah, I think it was patently wrong. I changed it so that connoinherit becomes true in this case. Alvaro Herrera wrote: > Jaime Casanova wrote: > > also noted that if you: > > > > """ > > create table t1(i int) partition by hash (i); > > create table t1_0 partition of t1 for values with (modulus 2, remainder 0); > > create table t1_1 partition of t1 for values with (modulus 2, remainder 1); > > create unique index on t1(i); > > alter table t1 add primary key using index t1_i_idx ; > > """ > > > > the ALTER TABLE ADD PK does not recurse to partitions, which maybe is > > perfectly fine because i'm using USING INDEX but it feels like an > > oversight to me > > Ouch. Yeah, this is a bug. I'll try to come up with something. After looking at it for a few minutes I determined that adding this feature requires some more work: you need to iterate on all partitions, obtain the corresponding index, cons up a few fake parse nodes, then recurse to create the PK in the children. I think this should be doable with a couple dozen lines of code, but it's a refinement that can be added on top. Care to submit a patch? In the meantime, I added an ereport(ERROR) to avoid leaving the system in an inconsistent state (that probably would not even be reproduced correctly by pg_dump). -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services