> I have tested this patch locally and did not encounter any failures. > I will take time to look the patch in detail and consider the issues you > mentioned.
Thanks for testing! I've spend some more time playing with this, and I confirmed my fears that it's possible to hit the case where one partition is added and another is removed, so the count of partitions is the same, yet their OIDs don't match (problem [2] in my previous email). This means we're forced to memcmp() the arrays even when nparts match. We can reuse the maps if the partition OID arrays are bitwise identical, otherwise we map the partitions one by one into subpart_map / subplan_map.
I ended up splitting the code fix in two parts, one for RelationBuildPartitionDesc and the other for CreatePartitionPruneState, because the two areas being touch have independent bugs that seem more easily explained separately. However, I was unable to trigger the bug that 0001 fixes without involving the code in 0002. The commit messges should explain each bug and fix in enough detail, I hope.
I‘m ok with 0001 and 0002. No failures any more on my machine.
I'm not happy about the comment changes in 0002: I think I'm losing some of the original comments that should perhaps be retained. I'll look into that, but I'll push 0001 soon.
(Both these patches are needed from 14 onwards, where DETACH CONCURRENTLY was added.)
-- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "In fact, the basic problem with Perl 5's subroutines is that they're not crufty enough, so the cruft leaks out into user-defined code instead, by the Conservation of Cruft Principle." (Larry Wall, Apocalypse 6)