Re: ATTACH/DETACH PARTITION CONCURRENTLY
От | Robert Haas |
---|---|
Тема | Re: ATTACH/DETACH PARTITION CONCURRENTLY |
Дата | |
Msg-id | CA+Tgmobq2iA3k8t20F-GZ_OQpLr05bmv9smcQf--ekkahE=dhw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ATTACH/DETACH PARTITION CONCURRENTLY (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: ATTACH/DETACH PARTITION CONCURRENTLY
Re: ATTACH/DETACH PARTITION CONCURRENTLY |
Список | pgsql-hackers |
On Mon, Feb 4, 2019 at 12:02 AM David Rowley <david.rowley@2ndquadrant.com> wrote: > If the PartitionDesc from the parallel worker has an extra partition > than what was there when the plan was built then the partition index > to subplan index translation will be incorrect as the > find_matching_subplans_recurse() will call get_matching_partitions() > using the context with the PartitionDesc containing the additional > partition. The return value from get_matching_partitions() is fine, > it's just that the code inside the while ((i = > bms_next_member(partset, i)) >= 0) loop that will do the wrong thing. > It could even crash if partset has an index out of bounds of the > subplan_map or subpart_map arrays. Is there any chance you've missed the fact that in one of the later patches in the series I added code to adjust the subplan_map and subpart_map arrays to compensate for any extra partitions? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: