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).
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.
Wyatt, what do you think?
--
Michael