David Rowley <dgrowleyml@gmail.com> writes:
> On Wed, 8 May 2024 at 10:40, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Didn't test, but that route seems awfully invasive and fragile: how
>> will we find all the places to modify, or ensure that the policy
>> is followed by future patches?
> REALLOCATE_BITMAPSETS was invented for this and IMO, it found exactly
> the problem it was invented to find.
Not in a way that gives me any confidence that we found *all* the
problems. If check-world finds a problem that the core tests did not,
then there's no reason to think there aren't still more issues that
check-world happened not to trip over either.
> Copy-on-modify is our policy for node mutation. Why is it ok there but
> awfully fragile here?
It's only partly our policy: there are all those places where we don't
do it that way. The main problem that I see for trying to be 100%
consistent in that way is that once you modify a sub-node, full
copy-on-modify dictates replacing every ancestor node all the way to
the top of the tree. That's clearly impractical in the planner data
structures. So where are we going to stop exactly?
regards, tom lane