From: Tom Lane <tgl@sss.pgh.pa.us>
To: exclusion@gmail.com
cc: pgsql-bugs@lists.postgresql.org,
        Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Subject: Re: BUG #17076: Server crashes on composing an error message about
 invalid modulus for a new table partition
In-reply-to: <17076-89a16ae835d329b9@postgresql.org>
References: <17076-89a16ae835d329b9@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Mon, 28 Jun 2021 16:00:00 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <342121.1624914489.1@sss.pgh.pa.us>
Date: Mon, 28 Jun 2021 17:08:09 -0400
Message-ID: <342122.1624914489@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/342122.1624914489%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> When executing the following query (based on create_table.sql):
> CREATE TABLE hash_parted (a int) PARTITION BY HASH (a);
> CREATE TABLE hpart_1 PARTITION OF hash_parted FOR VALUES WITH (MODULUS 10,
> REMAINDER 0);
> 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
> 150, REMAINDER 3);

> Server crashes with the following stack:

So this is evidently the fault of efbfb6424, which isn't accounting
for the possibility that the next remainder has no associated partition.
That results in boundinfo->indexes[offset + 1] being -1, whereupon we
pass garbage to get_rel_name() and get back a NULL.

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.

I'm inclined to think we should just revert efbfb6424, and maybe
try again some other time.

			regards, tom lane