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 1pIclj-0006iO-7S for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Jan 2023 21:48:23 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pIcle-0008AF-2y for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Jan 2023 21:48:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pIcld-00088M-Mf for pgsql-hackers@lists.postgresql.org; Thu, 19 Jan 2023 21:48:17 +0000 Received: from mail-qt1-x832.google.com ([2607:f8b0:4864:20::832]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pIclZ-0001W4-1e for pgsql-hackers@lists.postgresql.org; Thu, 19 Jan 2023 21:48:16 +0000 Received: by mail-qt1-x832.google.com with SMTP id x5so2736748qti.3 for ; Thu, 19 Jan 2023 13:48:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=xzilla-net.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WhivdgzFpXnotPlyz+djxfUqkIYBthYUzYFwINV0wjg=; b=xvv/w+IlVnWfZHFq9q3xTmAcnoUrPgR/QyH5v8lNs/aadZL8OaGkjHg0gM+Vb9DiW7 2aCR/KRmeP21VODBsG3Xnmn54gmdBCHaLqGDr2krBBwQXw6Rl72RWKtzLNH+lN/yWwZx HdA8lxREKEPzE6X13NuqEtFuB/3nqhegW0uBddLNIlU/9HwozWk8vDJIHMNghoft8itZ Q5C17x6guxlzNSYTZt+6lwFYYfX3w83cI+wmPKhkWNo1pj+jEt8H9CJUkXBkKGU3otzB sjvUeH9GfR3PPKBrwzw6VUiCzb4HMSlETNSwpSpjjliinnB+2+LKwMEB2hcCnAej207L rCEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WhivdgzFpXnotPlyz+djxfUqkIYBthYUzYFwINV0wjg=; b=qLudpR5I+SkZ3kVBV1ubzahZCoROKjqLdwuXMjgEl4ATr7rlLgYTUjvTQyEJQ532qR r8GvGRaiTWvP92zv3GnT+BDGNAsJuraAHu7LRwZcyy5QrY5oKZm/vt1EuafRCvd/KEND Z1wjeCLpmKuuzAlbq5hnw+zQD33hKQq0F3OD8xFSlNQF4lDo0iJRZesie3nd7b2zINZD j6OsVnfXhcYKiy9tndKkBzPXyJJMqQ1FPgBWqoT7qDI+56p2NyX9ZIeRWp5wdbk8GIfF N4a/4aVATVkME3tYzrX35mOhHgFkMxVzB5l2xexEi7mn2wQhzc7iJ8ZkYH9pMOgY5euD sMDw== X-Gm-Message-State: AFqh2krHDGGoy/X/pfcLdvnJRZELdrnVQqDhD3CnWhdpc015fyhU3RBX AdUrn553pPV3IrFsuU/gpa+4TuW2wqtJTPfMMSep5A== X-Google-Smtp-Source: AMrXdXtT1jHC+/DDGiXMsERGesDXeM3ihcPpI8mRswwzIoY8CIKsIukoIxz2Mt6pHi3pAnaR9FzjyB7NSIR3O9kFgrw= X-Received: by 2002:ac8:72ce:0:b0:3a9:7ff2:3b85 with SMTP id o14-20020ac872ce000000b003a97ff23b85mr484386qtp.102.1674164891061; Thu, 19 Jan 2023 13:48:11 -0800 (PST) MIME-Version: 1.0 References: <20220718143304.GC18011@telsasoft.com> <1e91af94-2bea-5b35-49f3-ea14859c2a0d@dunslane.net> <20220905180403.GN31833@telsasoft.com> In-Reply-To: From: Robert Treat Date: Thu, 19 Jan 2023 16:47:59 -0500 Message-ID: Subject: Re: doc: mentioned CREATE+ATTACH PARTITION as an alternative to CREATE TABLE..PARTITION OF To: Robert Haas Cc: Justin Pryzby , Andrew Dunstan , pgsql-hackers@lists.postgresql.org, David Rowley , Alvaro Herrera Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jan 11, 2023 at 4:13 PM Robert Haas wrote: > On Wed, Jan 11, 2023 at 10:48 AM Robert Treat wrote: > > > @Robert: I wonder why shouldn't CREATE..PARTITION OF *also* be patched > > > to first create a table, and then attach the partition, transparently > > > doing what everyone would want, without having to re-read the updated > > > docs or know to issue two commands? I wrote a patch for this which > > > "doesn't fail tests", but I still wonder if I'm missing something.. > > > > > > > I was thinking there might be either lock escalation issues or perhaps > > issues around index attachment that don't surface using create > > partition of, but I don't actually see any, in which case that does > > seem like a better change all around. But like you, I feel I must be > > overlooking something :-) > > To be honest, I'm not sure whether either of you are missing anything > or not. I think a major reason why I didn't implement this was that > it's a different code path. DefineRelation() has code to do a bunch of > things that are also done by ATExecAttachPartition(), and I haven't > gone through exhaustively and checked whether there are any relevant > differences. I think that part of the reason that I did not research > that at the time is that the patch was incredibly complicated to get > working at all and I didn't want to take any risk of adding things to > it that might create more problems. Now that it's been a few years, we > might feel more confident. > > Another thing that probably deserves at least a bit of thought is the > fact that ATTACH PARTITION just attaches a partition, whereas CREATE > TABLE does a lot more things. Are any of those things potential > hazards? Like what if the newly-created table references the parent > via a foreign key, or uses the parent's row type as a column type or > as part of a column default expression or in a CHECK constraint or > something? Basically, try to think of weird scenarios where the new > table would interact with the parent in some weird way where the > weaker lock would be a problem. Maybe there's nothing to see here: not > sure. > > Also, we need to separately analyze the cases where (1) the new > partition is the default partition, (2) the new partition is not the > default partition but a default partition exists, and (3) the new > partition is not the default partition and no default partition > exists. > > Sorry not to have more definite thoughts here. I know that when I > developed the original patch, I thought about this case and decided my > brain was full. However, I do not recall whether I knew about any > specific problems that needed to be fixed, or just feared that there > might be some. > I think all of that feedback is useful, I guess the immediate question becomes if Justin wants to try to proceed with his patch implementing the change, or if adjusting the documentation for the current implementation is the right move for now. Robert Treat https://xzilla.net