Re: BUG #17076: Server crashes on composing an error message about invalid modulus for a new table partition
От | Tom Lane |
---|---|
Тема | Re: BUG #17076: Server crashes on composing an error message about invalid modulus for a new table partition |
Дата | |
Msg-id | 342122.1624914489@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #17076: Server crashes on composing an error message about invalid modulus for a new table partition (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #17076: Server crashes on composing an error message about invalid modulus for a new table partition
|
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: