I've fixed the problems you mentioned (see attached) - sorry, I was a bit
careless with the docs.

> +               null_values = (Bitmapset *) WinGetPartitionLocalMemory(
> +                       winobj,
> +                       BITMAPSET_SIZE(words_needed));
> +               Assert(null_values);
> This certainly seems ugly - isn't there a way to accomplish this
> without having to violate the Bitmapset abstraction?

Indeed, it's ugly. I've revised it slightly to:

> null_values = (Bitmapset *) WinGetPartitionLocalMemory(
>    winobj,
>    BITMAPSET_SIZE(words_needed));
> null_values->nwords = (int) words_needed;

...which gives a proper bitmap. It's hard to break this into a factory
method like bms_make_singleton as I'm getting the (zero'ed) partition local
memory from one call, then forcing a correct bitmap's structure on it.
Maybe bitmapset.h needs an bms_initialise(void *, int num_words) factory
method? You'd still have to use the BITMAPSET_SIZE macro to get the correct
amount of memory for the void*. Maybe the factory method could take a
function pointer that would allocate memory of the given size (e.g.
Bitmapset* initialize(void* (allocator)(Size_t), int num_words) ) - this
means I could still use the partition's local memory.

I don't think the solution would be tidier if I re-instated the
leadlag_context struct with a single Bitmapset member. Other Bitmapset
usage seems to just call bms_make_singleton then bms_add_member over and
over again - which afaict will call palloc every BITS_PER_BITMAPWORD calls,
which is not really what I want.

Thanks -


Attachment: lead-lag-ignore-nulls.patch
Description: Binary data

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to