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 1hbW0R-0007as-Jc for pgsql-docs@arkaria.postgresql.org; Thu, 13 Jun 2019 20:07:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hbW0Q-0002Kx-7T for pgsql-docs@arkaria.postgresql.org; Thu, 13 Jun 2019 20:07:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hbW0P-0002Kq-Sw for pgsql-docs@lists.postgresql.org; Thu, 13 Jun 2019 20:07:30 +0000 Received: from mail-qt1-x844.google.com ([2607:f8b0:4864:20::844]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hbW0L-0003cN-Qf for pgsql-docs@lists.postgresql.org; Thu, 13 Jun 2019 20:07:28 +0000 Received: by mail-qt1-x844.google.com with SMTP id d23so24090066qto.2 for ; Thu, 13 Jun 2019 13:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=Jd8B2RVWW3UoB/owiId+dj/G0+eFTPsR5xR9IVbBH0U=; b=RQWER/AffP3b2q0Y+UjlzdsVwYadYDjgE8HRMqJ+VGILkAOCU5wDbsD6GxyZJQcNtT 0bao0wK4jnHI3njF+UUCHSMWmfAr6LgYv3sQvJbKd+fz/Gw7Q8YyKjH/LqKgFCZCdADt vlLJ9dG/y4XxHwjmDBJe4JxJZE2ye0Y+SEKq5igBqKNBvj7tTV8/R5/6unD5bPsEd1JA 1bpoyqfvwgQbs0fhh4rQNvwhMuA7UZjEQdLlcYLvcx+RwVHuIbXozPSoGetiaatrXKmB Xrry7wUTcSkf3U6c+3nzBayCzD4JzKXCUOwxkDBWXbfhFRRzBXz+GFj+ZiBbfJbCNDp3 rTsg== 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:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=Jd8B2RVWW3UoB/owiId+dj/G0+eFTPsR5xR9IVbBH0U=; b=sDJMUCbpzF17OuzTen1FrhArR61HjVFR7yFsY+HMPBXRfYpUCpbhr2RzYKUfxVDs1O YDbOmHZDf1LqUon5BNA+Po8JgNtnWZ+OqiCLJkvoOU5DrSWCEgqV8ox3h+eLQmC8Jmfu ceOibRo7RommsBrpT1tcmNGr+Yg10m0Q+BjcAZ7vOFJnRKqd2ps1dVADtO/ADwZhka2P 9SWiax5BQKWV5dFmO7zz4CbUlho0pmJCJ70vTi6Y/67ks2uGKllQJiuhQYhmFfblr5Tz B3LXQe21Yrn9wNgVljE/dbxlXH/22Z48XoMOjArS10ZjaKtz3VSbMK8VVGyP772swmqH eWIg== X-Gm-Message-State: APjAAAXbbln1nJ4sEs6c/MjEcEg6wDJy8i6l4VzsLiOKsRtMUv93r5OL mj6LWkj9pCUScQk2vna3v23ilTDGZ9wP/eX02h80cQmHFZB9VX5JOkrUSvtLO2m6Kk80IHVd+N0 g5ojb9JXe4/1of/sLQz7GiOpPgXa/XCw0Bzidd7drm1UaFqG+1p8j+ttYXXpgsy5Yho4K9L+OFO XZ54GJeZaKGw== X-Google-Smtp-Source: APXvYqyFzdg2GYobgrxIOMPZYDRENKH48KJlroK8drUbXThrrqugdrFqKNmNKYfroknMJhxSMWNWFg== X-Received: by 2002:ac8:2e5d:: with SMTP id s29mr68734356qta.70.1560456443426; Thu, 13 Jun 2019 13:07:23 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.121.29.3]) by smtp.gmail.com with ESMTPSA id u7sm441781qkm.62.2019.06.13.13.07.22 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 13 Jun 2019 13:07:23 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 90DB6120BA6; Thu, 13 Jun 2019 16:07:20 -0400 (-04) Date: Thu, 13 Jun 2019 16:07:20 -0400 From: Alvaro Herrera To: Pavel Luzanov Cc: pgsql-docs@lists.postgresql.org Subject: Re: ATTACH/DETACH partitions and locking Message-ID: <20190613200720.GA18557@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <642e9fbc-b832-698b-9a8f-d626afd7014d@postgrespro.ru> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Jun-13, Pavel Luzanov wrote: > Hello, > > According to patch[1] and after playing with v12 beta1 I think that this > item can be dropped from "5.11.3. Implementation Using Inheritance" section > of v12 docs: > > "Some operations require a stronger lock when using declarative partitioning > than when using table inheritance. For example, adding or removing a > partition to or from a partitioned table requires taking an ACCESS EXCLUSIVE > lock on the parent table, whereas a SHARE UPDATE EXCLUSIVE lock is enough in > the case of regular inheritance." Hmm ... while you're correct that ALTER TABLE ATTACH PARTITION no longer uses AccessExclusive lock, ALTER TABLE DETACH PARTITION continues to. So we could remove the "adding to" bit of the paragraph, but not remove it completely. https://www.postgresql.org/message-id/CA%2BTgmoY13KQZF-%3DHNTrt9UYWYx3_oYOQpu9ioNT49jGgiDpUEA%40mail.gmail.com -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services