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 1lxzm4-0001UA-2R for pgsql-bugs@arkaria.postgresql.org; Mon, 28 Jun 2021 22:30:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lxzm1-00030Z-Uf for pgsql-bugs@arkaria.postgresql.org; Mon, 28 Jun 2021 22:30:37 +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 1lxzm1-0002z4-Nz for pgsql-bugs@lists.postgresql.org; Mon, 28 Jun 2021 22:30:37 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lxzlz-0007N6-O3 for pgsql-bugs@lists.postgresql.org; Mon, 28 Jun 2021 22:30:36 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 15SMUWka346712; Mon, 28 Jun 2021 18:30:32 -0400 From: Tom Lane To: Peter Eisentraut cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17076: Server crashes on composing an error message about invalid modulus for a new table partition In-reply-to: <342122.1624914489@sss.pgh.pa.us> References: <17076-89a16ae835d329b9@postgresql.org> <342122.1624914489@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Mon, 28 Jun 2021 17:08:09 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <346710.1624919432.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Jun 2021 18:30:32 -0400 Message-ID: <346711.1624919432@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > I think the patch has got more problems than that too, as it's far > from clear why the next remainder would have anything to do with the > next larger modulus. IOW I suspect that when it does manage to print > a partition name without crashing, it's very likely to print the > wrong partition. Concretely, this variant of the test case: drop table hash_parted; CREATE TABLE hash_parted ( a int ) PARTITION BY HASH (a); CREATE TABLE hpart_1 PARTITION OF hash_parted FOR VALUES WITH (MODULUS 50,= REMAINDER 0); CREATE TABLE hpart_2 PARTITION OF hash_parted FOR VALUES WITH (MODULUS 10,= REMAINDER 1); CREATE TABLE hpart_3 PARTITION OF hash_parted FOR VALUES WITH (MODULUS 200= , REMAINDER 2); CREATE TABLE fail_part PARTITION OF hash_parted FOR VALUES WITH (MODULUS 2= 5, REMAINDER 3); prints ERROR: every hash partition modulus must be a factor of the next larger m= odulus DETAIL: The new modulus 25 is not divisible by 10, the modulus of existin= g partition "hpart_1". which is obviously wrong. I think that rescuing this might require scanning through the list of partitions for one that has the desired modulus. There could be more than one match, but I'd be content to take the first one. regards, tom lane