On Tue, 16 Jan 2024 at 21:00, Richard Guo wrote:
> Thank you so much for all the work you have put into making this patch
> perfect. I reviewed through the v3 patch and I do not have further
> comments. I think it's in good shape now.
Thanks for looking again. I pushed the patch after removing
On Tue, Jan 16, 2024 at 11:08 AM David Rowley wrote:
> I've now adjusted the patch to have all modifications to Bitmapsets
> return a newly allocated set. There are a few cases missing in master
> that need to be fixed (items 6-10 below):
>
> The patch now includes changes for the following:
>
>
On Tue, 2 Jan 2024 at 20:18, Richard Guo wrote:
> I think one purpose of introducing REALLOCATE_BITMAPSETS is to help find
> dangling pointers to Bitmapset's. From this point of view, I agree that
> we should call bms_copy_and_free() in bms_add_members(), because the
> bitmapset 'a' might be recy
On Sun, Dec 31, 2023 at 6:44 AM David Rowley wrote:
> On Fri, 29 Dec 2023 at 23:38, Richard Guo wrote:
> > After applying this process to the first RestrictInfo, the bitmapset now
> > becomes {t2, t3}. Consequently, the second RestrictInfo also perceives
> > {t2, t3} as its required_relids. As
On Fri, 29 Dec 2023 at 23:38, Richard Guo wrote:
> After applying this process to the first RestrictInfo, the bitmapset now
> becomes {t2, t3}. Consequently, the second RestrictInfo also perceives
> {t2, t3} as its required_relids. As a result, when attempting to remove
> it from the joininfo li
On Fri, Dec 29, 2023 at 5:22 PM David Rowley wrote:
> On Fri, 29 Dec 2023 at 21:07, Richard Guo wrote:
> > It seems to me that the former scenario also makes sense in some cases.
> > For instance, let's say there are two pointers in two structs, s1->p and
> > s2->p, both referencing the same bit
On Fri, 29 Dec 2023 at 21:07, Richard Guo wrote:
> It seems to me that the former scenario also makes sense in some cases.
> For instance, let's say there are two pointers in two structs, s1->p and
> s2->p, both referencing the same bitmapset. If we modify the bitmapset
> via s1->p (even if no re
On Fri, Dec 29, 2023 at 9:15 AM David Rowley wrote:
> I looked into this a bit more and I just can't see why the current
> code feels like it must do the reallocation in functions such as
> bms_del_members(). We don't repalloc the set there, ever, so why do
> we need to do it when building with
On Thu, 28 Dec 2023 at 23:21, David Rowley wrote:
> then instead of having to do:
>
> #ifdef REALLOCATE_BITMAPSETS
> a = (Bitmapset *) palloc(BITMAPSET_SIZE(tmp->nwords));
> memcpy(a, tmp, BITMAPSET_SIZE(tmp->nwords));
> pfree(tmp);
> #endif
>
> all over the place. Couldn't we do:
>
> #ifdef REAL
On Wed, 27 Dec 2023 at 22:30, Richard Guo wrote:
> The Asserts added to bitmapset.c by commits 71a3e8c43b and 7d58f2342b
> contain some duplicates, such as in bms_difference, bms_is_subset,
> bms_subset_compare, bms_int_members and bms_join. For instance,
I'm just learning of these changes now.
The Asserts added to bitmapset.c by commits 71a3e8c43b and 7d58f2342b
contain some duplicates, such as in bms_difference, bms_is_subset,
bms_subset_compare, bms_int_members and bms_join. For instance,
@@ -953,6 +1033,15 @@ bms_int_members(Bitmapset *a, const Bitmapset *b)
int
11 matches
Mail list logo
