Re: BUG #17076: Server crashes on composing an error message about invalid modulus for a new table partition
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2021-06-28T22:30:32Z
Lists: pgsql-bugs
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 25, REMAINDER 3); prints ERROR: every hash partition modulus must be a factor of the next larger modulus DETAIL: The new modulus 25 is not divisible by 10, the modulus of existing 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
Commits
-
Fix bogus logic for reporting which hash partition conflicts.
- f8b51464c265 14.0 landed
- dd2364ced985 15.0 landed