Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gjUeN-0004q4-Uy for pgsql-bugs@arkaria.postgresql.org; Tue, 15 Jan 2019 19:45:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gjUeL-0005Qh-Q8 for pgsql-bugs@arkaria.postgresql.org; Tue, 15 Jan 2019 19:45:25 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gjUeL-0005QI-HK for pgsql-bugs@lists.postgresql.org; Tue, 15 Jan 2019 19:45:25 +0000 Received: from mail-qt1-f176.google.com ([209.85.160.176]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gjUe3-0003iH-GA for pgsql-bugs@lists.postgresql.org; Tue, 15 Jan 2019 19:45:24 +0000 Received: by mail-qt1-f176.google.com with SMTP id d19so4364689qtq.9 for ; Tue, 15 Jan 2019 11:45:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :organization:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=EklTItw42Pi6iGjc3sOWKUCjzF0ybqHJvHk99GKmyD8=; b=P2zPdzs8Gdmf0QBPfbW+S6OKTg0hmCQTTzRnqm4DGUUHI2QE8LdHoiu3H27kAFiu/n wReWRJODPTQv6BA2PICGwD5R4gsxEoxvMsR2K7yTd3RHHAWIqWYnldwWD8XNh7H82cmC 9xmSEdqOISKe+4FfUpeCeEpV7WUpIpBNcIKKzyVK0kIULuxN6okyjjkcuWCNUnZK/kdC NCy3+1GxjRkajjfQ/CorX6kb+U2+E+dK1MDokDnsdioH7nTa9yQa2o585lg3q4EI7j+D gYKMAH8ZHhbI3tzFJtjBb/oYxrVb45zs0wDhxkrwMU0/2E826f99rzRyn8axyk0G9PVB 3HVw== X-Gm-Message-State: AJcUukfmStMUR9pW8vu5h0M/ogGb9riicQhGQsXZ+T7Tfe24Di3sm2d/ rpP925dkraZ95wcZXjzFETfqtaRLUfw= X-Google-Smtp-Source: ALg8bN7tvNtY3Guo0x69X+zZnLAPjVw6UX3oAD14dIwmNfdVfrd25UI5q+QPeSxASeEQzW127W08HA== X-Received: by 2002:ac8:738e:: with SMTP id t14mr4170559qtp.283.1547581505556; Tue, 15 Jan 2019 11:45:05 -0800 (PST) Received: from localhost.localdomain (c-24-61-8-151.hsd1.ma.comcast.net. [24.61.8.151]) by smtp.gmail.com with ESMTPSA id y4sm56066290qtc.47.2019.01.15.11.45.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Jan 2019 11:45:04 -0800 (PST) Reply-To: jesper.pedersen@redhat.com Subject: Re: BUG #15587: Partitions with ALTER TABLE ADD CONSTRAINT To: Alvaro Herrera , Tom Lane Cc: pgsql-bugs@lists.postgresql.org References: <201901151935.zfadrzvyof4k@alvherre.pgsql> From: Jesper Pedersen Organization: Red Hat Message-ID: Date: Tue, 15 Jan 2019 14:45:03 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <201901151935.zfadrzvyof4k@alvherre.pgsql> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi, On 1/15/19 2:35 PM, Alvaro Herrera wrote: > On 2019-Jan-15, Tom Lane wrote: >> Alvaro Herrera writes: >>> I haven't investigated this angle. It seems more complex than just a >>> simple bugfix, right? >> >> Wouldn't that be throwing away the entire point of the ONLY behavior, >> ie to allow the component indexes to be built one at a time, without >> holding locks across the whole partition tree? > > I now see that Jesper was talking about a completely different thing > than I was thinking. I agree with you there -- it makes no sense to > reject that command ... particularly because pg_dump uses it. > I now think Tom is correct that it is UX and documentation issue, and changing the existing behavior is probably not a good thing. Changing "invalid" to "incomplete" would be a good idea. Maybe "partial" could be a good descriptor if not all partitions shares the unique constraint. Best regards, Jesper