Re: BUG #18135: Incorrect memory access occurs when attaching a partition with an index
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2023-10-01T00:39:37Z
Lists: pgsql-bugs
Michael Paquier <michael@paquier.xyz> writes: > I can see that this has already been committed as 9f71e10d65, but are > you sure that this is correct? I didn't take the time to reply back, > because I got the feeling that even what I proposed is not correct. > The previous code was careful enough to look at the information from > info2 only *through* the attribute map, which is not what this new > code is doing. Rather than looking directly at the elements in info2 > at each iteration, shouldn't this stuff loop over the elements in > attmap->attnums for each info1->ii_IndexAttrNumbers[i]? I think it's OK as is. What we are comparing in the modified logic is whether index columns at the same column positions are expressions or not, and that's not a matter for mapping. Once we've verified that the current column is a non-expression in both indexes, then it's appropriate to use the attmap to see whether the columns correspond. (Or to put it another way: running "column zero" through the attmap is always the wrong thing.) regards, tom lane
Commits
-
Fix checking of index expressions in CompareIndexInfo().
- 3caedf246123 11.22 landed
- d6425987ba76 12.17 landed
- 9f71e10d65fa 17.0 landed
- 9d6d8d7049ea 14.10 landed
- 83ba050f92fa 13.13 landed
- 59371f1aeb9a 15.5 landed
- 12402b93117b 16.1 landed