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 1qE6Qf-00088O-8Y for pgsql-bugs@arkaria.postgresql.org; Tue, 27 Jun 2023 11:00:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qE6Qd-0007Ea-UE for pgsql-bugs@arkaria.postgresql.org; Tue, 27 Jun 2023 11:00:11 +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 1qE6Qd-0007ER-LK for pgsql-bugs@lists.postgresql.org; Tue, 27 Jun 2023 11:00:11 +0000 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qE6QX-000inH-7O for pgsql-bugs@lists.postgresql.org; Tue, 27 Jun 2023 11:00:10 +0000 Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2b5e7dba43cso43158131fa.1 for ; Tue, 27 Jun 2023 04:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687863603; x=1690455603; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=1+JGUbWBBmE0q1xYtPj3HWYblDK9KCtQEi2/butsZmc=; b=ZDS0Uadrau3GznwbjV8fcxrt/h9uWgSiN6Ypw67Q2h3lVnzPtY6RQrdZ3PEPlRlfej NHieQ/j6oTiVA7Ey/C+OijAfg/jTHfpwEQQ9M97MyJAxtGIur7ZmzLL0UVqKyRHCfpaJ Ftduz6Zcpaa7W6Kfva0yg2j+7OJrLYRciOlXUwQACgbK0XACboQf+0/inzV5zWHqJw8E heiLouOdYOyfImkhFBXvl+jHsqCAqvX3tVWylXwkk47TEg4sBy/tVKxjJuN3EZn7BgrB RyFIyXRUYRaPeLmj928JCnWXZNHZuT8w6ck/wDxCDhwYZl19xPW1zkMoH4eiBUUHRyBZ m4kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687863603; x=1690455603; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=1+JGUbWBBmE0q1xYtPj3HWYblDK9KCtQEi2/butsZmc=; b=OGIMFfUB/yMwdG/qIMPMLuZj4dp9NA6SBl7H0LvplIn5D67GLl3w6yhLB0aGJyG82C X60HH+3JTdSEp2QcEI4fpz8UHAROnnQEAMRV8vXqRviJy0EFpNjL5XdeSAM6D0lvsfrI KceOLCQDc3jCDV5UY0GyH4yMAItPaD/ZbWMbils7Lg5EuFYUk+DTg3Z+7SzMm9fIdxi5 s1pqKYDAhF9fxHdQ7z8nGp08Dc0FoDGbkKSy96XS7+sq4N5lQM4oLNr7JJoHAiUjqEBU AjlysYCjy8/xAfwMoJ8P56FJ4slnRUP2tFUGLuiqs3iIUDpngVVqBp4rf4FV2qQvqfbw 0CRA== X-Gm-Message-State: AC+VfDz7GPJoeEfMb3u1TNPBLW1ccC5BrCrNgdRZgik3IXKlFWngQmsl TOE07HIACuEabmSPUmn8wxF/6vxzkJM= X-Google-Smtp-Source: ACHHUZ4XuHnMJfY9NXYGl16lkMEtV8wfmp9rocd9ASnYhtieBLgQVYYWGaTv+iosMk/foxg3LduVrw== X-Received: by 2002:a2e:9d4e:0:b0:2b4:67e0:4ce0 with SMTP id y14-20020a2e9d4e000000b002b467e04ce0mr15597743ljj.44.1687863602682; Tue, 27 Jun 2023 04:00:02 -0700 (PDT) Received: from [1.0.0.7] ([178.155.23.108]) by smtp.gmail.com with ESMTPSA id z20-20020a2e8e94000000b002af8aaebce4sm1687169ljk.8.2023.06.27.04.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Jun 2023 04:00:01 -0700 (PDT) Message-ID: <14987634-43c0-0cb3-e075-94d423607e08@gmail.com> Date: Tue, 27 Jun 2023 14:00:00 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: BUG #17997: Assert failed in validatePartitionedIndex() when attaching partition index to child of valid index Content-Language: en-US To: Michael Paquier , Tom Lane Cc: pgsql-bugs@lists.postgresql.org References: <17997-a044c27aef95daf8@postgresql.org> <509915.1687704058@sss.pgh.pa.us> From: Alexander Lakhin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 26.06.2023 11:05, Michael Paquier wrote: > A third solution that came into my mind just now would be to revisit > the choice done in AttachPartitionEnsureIndexes() where an invalid > index can be chosen as a match when creating the indexes on the > partitions, so as we are able to get to the bottom of a chain with > valid indexes for the whole tree. I have been testing the attached > and it has been working here the way I'd expect when manipulating > partition trees with ATTACH PARTITION, though this breaks the scenario > of this bug report because we would now get a failure when attempting > to attach an index in the last command. Thanks for the fix! This solution seems sensible to me. The only downside I see is that an invalid index would be left orphaned after ATTACH PARTITION, but I couldn't find in doc/ or src/test/regress/ any promises that such index must be used. I also don't see a way to make a previously valid index inside the partition index tree invalid and available to attaching a child index to it in the same time. Beside that, maybe it would be better to place the test for the fix in indexing.sql, where many similar operations with partitioned indexes are performed. Best regards, Alexander