agora inbox for pgsql-committers@postgresql.org  

help / color / mirror / Atom feed

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Clean up all relid fields of RestrictInfos during join removal.
Date: Mon, 20 Apr 2026 19:38:06 -0400
Message-ID: <466111.1776728286@sss.pgh.pa.us> (raw)
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>

Richard Guo <guofenglinux@gmail.com> writes:
> On Tue, Apr 21, 2026 at 8:03 AM Michael Paquier <michael@paquier.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

view thread (7+ messages)

Message-ID: <466111.1776728286@sss.pgh.pa.us>
Permalink:  ../466111.1776728286@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/466111.1776728286@sss.pgh.pa.us

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-committers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, guofenglinux@gmail.com, michael@paquier.xyz, pgsql-committers@lists.postgresql.org
  Subject: Re: pgsql: Clean up all relid fields of RestrictInfos during join removal.
  In-Reply-To: <466111.1776728286@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox