On Thu, Oct 31, 2019 at 1:45 PM Michael Paquier <mich...@paquier.xyz> wrote: > On Tue, Oct 29, 2019 at 01:16:58PM +0900, Michael Paquier wrote: > > Yes, something looks wrong with that. I have not looked at it in > > details yet though. I'll see about that tomorrow. > > So.. When building the attribute map for a cloned index (with either > LIKE during the transformation or for partition indexes), we store > each attribute number with 0 used for dropped columns. Unfortunately, > if you look at the way the attribute map is built in this case the > code correctly generates the mapping with convert_tuples_by_name_map. > But, the length of the mapping used is incorrect as this makes use of > the number of attributes for the newly-created child relation, and not > the parent which includes the dropped column in its count. So the > answer is simply to use the parent as reference for the mapping > length. > > The patch is rather simple as per the attached, with extended > regression tests included. I have not checked on back-branches yet, > but that's visibly wrong since 8b08f7d down to v11 (will do that when > back-patching).
The patch looks correct and applies to both v12 and v11. > There could be a point in changing convert_tuples_by_name_map & co so > as they return the length of the map on top of the map to avoid such > mistakes in the future. That's a more invasive patch not really > adapted for a back-patch, but we could do that on HEAD once this bug > is fixed. I have also checked other calls of this API and the > handling is done correctly. I've been bitten by this logical error when deciding what length to use for the map, so seems like a good idea. Thanks, Amit