Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lMbAu-0003Dk-HO for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Mar 2021 18:45:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lMbAs-00068Y-7S for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Mar 2021 18:45:42 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lMbAr-00068P-O4 for pgsql-hackers@lists.postgresql.org; Wed, 17 Mar 2021 18:45:41 +0000 Received: from mail-io1-xd35.google.com ([2607:f8b0:4864:20::d35]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1lMbAn-0007EI-EE for pgsql-hackers@lists.postgresql.org; Wed, 17 Mar 2021 18:45:40 +0000 Received: by mail-io1-xd35.google.com with SMTP id w11so242240iol.13 for ; Wed, 17 Mar 2021 11:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=rPPpyThyy39VqPVJ7nlDOnSS9WfPmT3ZIzWJimjpx5Y=; b=WshQtNlwRg8/MM4zfO7Li/DbwB/hMJbmvOi7hDrJKAILdEy1nle9ust1zNrPJe15pP jbmjyFwLhvbqZnAMDBurbyXawAr2QRh5HBftw0MUET38iNFFgdekPXZu2kGCsWUAyF0l oXNvfL8WECk5AmSlyDILDmcS/U7QDbdUIZ2O0s05Z1qG3GamZMkPdzrWpAIdtdBl8yoJ 8phco+iHmrmpxgXO4NlCymguS/kzXUfgaT++uXOy4Kr8vtHLqWkoEqceHqrEjiU3nvHl 2fLxl+5BYi7kLQ7aPx7E48T0xYEmqePHD2KXilXhWnPWr1DtgkgQYrcq3Rs27EqHCyCo xzkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=rPPpyThyy39VqPVJ7nlDOnSS9WfPmT3ZIzWJimjpx5Y=; b=YgxDF/WeACTeU949ur6KgFQVCFl0U323XR0dXdLKHp0IagvFbrLboIeNFYf3eprT2s MxvmzcDU9TJL/3Q18G7SK9/H+nSx4SAhWKlBcTSbDJskcch6NfeDNHskuVEY4tOVYCg3 QoZLjcXrAjmHuaQuFoLH23NStFQLch46Jjtem/u3NV6+BUvK6v0Z9gm/E0jtFWfXTboI iWsA1byx54OXcmgyt/qnQGExaUjyIfuKTkmj7WgJTCNi37AD0sde6id5h5fhzpTFgOof Pd0ddOa1tD9m5E7pyeiKhWWQ5vGAWpf3b0lbuhnIzd9pAnm7VXNRQ6HSdadCwyQGl+Ab Oj8w== X-Gm-Message-State: AOAM531FQjtDRNzEpY8J91zliCpgrdP9YrS+fHj27fxwyQRcD5SZ6Bwl ZPNZfgZ0YRnARPWPZtWRJMnHsw== X-Google-Smtp-Source: ABdhPJyAGjQknF3gs+83b5hVehKpt0h1h+x4DTVUfi7HAVGhIFBbLa8i0KwBZmJ0pplAmMUtHCCXqA== X-Received: by 2002:a6b:ec14:: with SMTP id c20mr8027923ioh.122.1616006736396; Wed, 17 Mar 2021 11:45:36 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id s9sm10245877iob.33.2021.03.17.11.45.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Mar 2021 11:45:35 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 88FEE801407; Wed, 17 Mar 2021 13:45:34 -0500 (CDT) Date: Wed, 17 Mar 2021 13:45:34 -0500 From: Justin Pryzby To: Alvaro Herrera Cc: Amit Langote , pgsql-hackers@lists.postgresql.org Subject: Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY Message-ID: <20210317184534.GB11765@telsasoft.com> References: <20210315230437.GA20801@alvherre.pgsql> <20210317174843.GA29968@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210317174843.GA29968@alvherre.pgsql> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk The v8 patch has the "broken constraint" problem. Also, it "fails to avoid" adding duplicate constraints: Check constraints: "c" CHECK (i IS NOT NULL AND i > 1 AND i < 2) "cc" CHECK (i IS NOT NULL AND i >= 1 AND i < 2) "p1_check" CHECK (true) "p1_i_check" CHECK (i IS NOT NULL AND i >= 1 AND i < 2) > diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml > index 5c9f4af1d5..0cb846f408 100644 > --- a/doc/src/sgml/catalogs.sgml > +++ b/doc/src/sgml/catalogs.sgml > @@ -4485,6 +4485,16 @@ SCRAM-SHA-256$<iteration count>:&l > when using declarative partitioning. > > > + > + > + > + inhdetachpending bool > + > + > + Set to true for a partition that is in the process of being detached; > + false otherwise. > + > + Remove "Set to" ? And say true and false Probably you'll hate the suggestion, but maybe it should be "pendingdetach". We already have pg_settings.pending_restart. > + If CONCURRENTLY is specified, this process runs in two > + transactions in order to avoid blocking other sessions that might be accessing > + the partitioned table. During the first transaction, a > + SHARE UPDATE EXCLUSIVE lock is taken on both parent table and > + partition, and its partition is marked detached; at that point, the transaction > + is committed and all transactions using the partitioned table are waited for. > + Once all those transactions are gone, the second stage acquires Instead of "gone", say "have completed" ? > +/* > + * MarkInheritDetached > + * > + * When a partition is detached from its parent concurrently, we don't > + * remove the pg_inherits row until a second transaction; as a preparatory > + * step, this function marks the entry as 'detached', so that other *pending detached > + * The strategy for concurrency is to first modify the partition catalog > + * rows to make it visible to everyone that the partition is detached, the inherits catalog? > + /* > + * In concurrent mode, the partition is locked with share-update-exclusive > + * in the first transaction. This allows concurrent transactions to be > + * doing DML to the partition. > + /* > + * Check inheritance conditions and either delete the pg_inherits row > + * (in non-concurrent mode) or just set the inhisdetached flag. detachpending