Re: Wrong results with initplans moved by setrefs.c

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Wrong results with initplans moved by setrefs.c
Date: 2026-11-09 05:11:37
Message-ID: CAApHDvo59O6AXcNvRdhxuKKgHqy0Nyw+Ztgm5wTZfEpbB3NbwQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 9 Nov 2026 at 15:54, Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> I think the fix is simply to merge the removed node's extParam and
> allParam into the child's, something like below in
> clean_up_removed_plan_level():
>
> child->initPlan = list_concat(parent->initPlan,
> child->initPlan);
> +
> + child->extParam = bms_union(child->extParam, parent->extParam);
> + child->allParam = bms_union(child->allParam, parent->allParam);

Looking at finalize_plan(), I'd say that's correct. But shouldn't it
be bms_add_member() rather than bms_union()? While mostly harmless, I
don't think creating a new set is the correct thing to do here. I
think doing bms_union() where the variable being assigned is the same
as the bms_union's first parameter is only valid in cases where you
don't want the first parameter to be modified, e.g in cases like
createplan.c:4325 where req_outer points to some field in a struct. I
think all the cases where we're assigning bms_union's return to a
struct field and that field is the same as the bms_union's first input
are probably all candidates for using bms_add_member() instead.
REALLOCATE_BITMAPSETS was designed to help identify cases where
Bitmapset pointers are being shared. I'm personally not so keen on
adjusting the other existing ones due to the poor risk to reward
ratio, but since you're adding these lines, I'd say bms_add_member is
a better option.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2026-11-09 05:30:13 Re: Proposal: Conflict log history table for Logical Replication
Previous Message Nitin Jadhav 2026-11-09 05:10:16 Re: Reporting WAL replay progress during pre-consistency standby reovery