Re: [BUG] Partition creation fails after dropping a column and adding a partial index
Ibrar Ahmed <ibrar.ahmad@gmail.com>
From: Ibrar Ahmed <ibrar.ahmad@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Wyatt Alt <wyatt.alt@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-10-31T14:54:25Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix failure when creating cloned indexes for a partition
- f10815c5bf1b 11.6 landed
- 7963c4c4b782 12.1 landed
- dc816e581591 13.0 landed
Attachments
- partition-drop-col_rel11.patch (application/x-patch) patch
On Thu, Oct 31, 2019 at 9:45 AM Michael Paquier <michael@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). > > 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. > > The patch works for me on master and on 12. I have rebased the patch for Version 11. > Wyatt, what do you think? > -- > Michael > -- Ibrar Ahmed