Re: pgsql: Clean up all relid fields of RestrictInfos during join removal.

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> On Tue, Apr 21, 2026 at 8:03 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> prion looks unhappy on this one:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2026-04-20%2022%3A50%3A01
>> This uses -DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE.

> This seems the same problem as in skink.

Yeah, likely. As best I can tell, the reason skink is falling over is
that USE_VALGRIND enables list.c's DEBUG_LIST_MEMORY_USAGE, making
list.c much more memory-hungry and thus able to recycle freed
bitmapset storage before it would have been recycled in a regular
debug build. Probably prion's options have a similar effect.

Wanting to get the buildfarm green again, I didn't stop to dig into
this interesting question: how the heck did cfcd57111 manage to pass
regression testing in our standard test rig with CLOBBER_FREED_MEMORY
enabled? In the problematic cases, remove_rel_from_eclass reduces
cur_em->em_relids to empty causing it to be pfree'd, which means that
there is now some associated RestrictInfo whose left_relids or
right_relids is pointing at freed memory. That should result in the
later bms_del_member calls in remove_rel_from_restrictinfo blowing up
instantly on Assert(bms_is_valid_set(a)). The only way that doesn't
happen, AFAICS, is if we repopulate that freed chunk with another
Bitmapset in between. It's certainly possible given that the loop in
remove_rel_from_restrictinfo will do some bms_copy's, but you would
not think it'd happen that way reliably enough to get through
check-world.

regards, tom lane