Re: [HACKERS] UPDATE of partition key
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] UPDATE of partition key |
Дата | |
Msg-id | CA+TgmobjLb9tWv-yeKNrdYxGro7BeyDhwyvZp0_uMh09jHudaA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] UPDATE of partition key (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] UPDATE of partition key
|
Список | pgsql-hackers |
On Sun, Jan 21, 2018 at 1:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> Committed with a bunch of mostly-cosmetic revisions. > > Buildfarm member skink has been unhappy since this patch went in. > Running the regression tests under valgrind easily reproduces the > failure. Now, I might be wrong about which of the patches committed > on Friday caused the unhappiness, but the valgrind backtrace sure > looks like it's to do with partition routing: Yeah, that must be the fault of this patch. We assign to proute->subplan_partition_offsets[update_rri_index] from update_rri_index = 0 .. num_update_rri, and there's an Assert() at the bottom of this function that checks this, so probably this is indexing off the end of the array. I bet the issue happens when we find all of the UPDATE result rels while there are still partitions left; then, subplan_index will be equal to the length of the proute->subplan_partition_offsets array and we'll be indexing just off the end. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: