From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
cc: Michael Paquier <michael@paquier.xyz>,
        pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Clean up all relid fields of RestrictInfos during join
 removal.
In-reply-to: 
 <CAMbWs4-FS=RLm4beNYR+5CYDDJxq6RU1FFAWqxYGZJDGFAfjZA@mail.gmail.com>
References: <E1wEtfe-001tkg-1d@gemulon.postgresql.org>
 <aeawnyFl5lwsG2dC@paquier.xyz>
 <CAMbWs4-FS=RLm4beNYR+5CYDDJxq6RU1FFAWqxYGZJDGFAfjZA@mail.gmail.com>
Comments: In-reply-to Richard Guo <guofenglinux@gmail.com>
	message dated "Tue, 21 Apr 2026 08:08:40 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <466110.1776728286.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 20 Apr 2026 19:38:06 -0400
Message-ID: <466111.1776728286@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/466111.1776728286%40sss.pgh.pa.us>
Precedence: bulk

Richard Guo <guofenglinux@gmail.com> writes:
> On Tue, Apr 21, 2026 at 8:03=E2=80=AFAM Michael Paquier <michael@paquier=
.xyz> wrote:
>> prion looks unhappy on this one:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dprion&dt=3D20=
26-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