MIME-Version: 1.0
References: <CA+HiwqFpZ80UJKr4tZus4Omgg7YESzFXKSwSHRW2Ap2=XSVyUA@mail.gmail.com>
 <CA+HiwqH9u1RWn9OEa=VQQpJagB0hDLCY+=fSyBC4ZkeU6Gg2HA@mail.gmail.com>
 <CA+HiwqFMWt2MQVqhp2rZA8=ugPVD=5uW10QCdK_NpoyWyFLe-g@mail.gmail.com>
 <CA+HiwqGBpw_JNwkwZjQ2YaqTWrDjn9L5jpuc+nS8=a55SPD+UA@mail.gmail.com>
 <CA+HiwqFGz2uShfU=qtack9gii6Kzyjv1V66tJJBYBN8Acb4uTA@mail.gmail.com>
 <CA+HiwqE7+iwMH4NYtFi28Pt9fT_gRW+Gt-=CvOX=Pkquo=AN8w@mail.gmail.com>
 <CA+TgmobO_6irkJGkzkxHTR=kza_CG+0idAhFUWqGfXCVQQmuPg@mail.gmail.com>
 <CA+HiwqH45ZCQkWoLzjOyS6bQ9QsF7yDCKVwiEUtB_RwPFwLmQg@mail.gmail.com>
 <CA+HiwqHRRFQN6yZ54fBydOTM6ncqZBCmewZ6n519RjRdDsO44g@mail.gmail.com>
 <54c35fb9-da3a-4754-ab8c-46ed0b612465@vondra.me> <CA+HiwqH8N-SxEB6SysEBsYNgV_KJs66k9Z2SNmqVzbBP-60yWg@mail.gmail.com>
 <684c70d7-180e-461d-9377-600c2db581ba@vondra.me> <CA+HiwqEmG9YCQvG6uux7sO=jKFSAW6hA4Ea-ymfD+JhJAe4PWQ@mail.gmail.com>
 <CA+HiwqE2FfJfH=siLiR3kJ13tmXZORAGTWsZc2r52o1_5BDv+g@mail.gmail.com>
 <bfcc1b78-aa39-4356-8f42-b8cfb9733d6e@vondra.me> <CA+HiwqHOejJk0_qMuM5g38h70hY_JvHMAKwnH3k=urfTXauPQA@mail.gmail.com>
 <CA+HiwqFsGKM82oaMby3VWYXf_XFpDAMeT+6SXgj-45HpTrS1dA@mail.gmail.com>
 <CA+HiwqFA5hUWYktt3VMh4zQOYMxqH-MpdX8eemfM+o-9dY-zbQ@mail.gmail.com>
 <CA+HiwqEn7bbUXaXO=SmUujBjJSHfS31cwQroHRBwT0sR=66bgg@mail.gmail.com>
 <CA+HiwqGGLDTd1ZTK1c0zv4La7XOVSVMqBuNtscJeh6FyUQvFvA@mail.gmail.com>
 <CA+HiwqE2JFiqqrXdyJVQWY-fMGwzDkLqjXQdUKbPaCpDpxd_2g@mail.gmail.com>
 <2990641.1740117879@sss.pgh.pa.us> <CA+HiwqHdw8meEiCC0=TrOCymPXiacM2NcRSGiEbkQeKJ-PLJag@mail.gmail.com>
 <CA+HiwqEaFnw3Am6rPw_y-vz7Eq63KoAi=oD_+tH4R8XWMg+acg@mail.gmail.com>
 <3132441.1740153303@sss.pgh.pa.us> <CA+HiwqHEy7OLWG1-FZ8XfCzjuLQR_mytu9aYxbtPrs_0NeDYkg@mail.gmail.com>
In-Reply-To: <CA+HiwqHEy7OLWG1-FZ8XfCzjuLQR_mytu9aYxbtPrs_0NeDYkg@mail.gmail.com>
From: Amit Langote <amitlangote09@gmail.com>
Date: Sat, 22 Feb 2025 15:29:25 +0900
Message-ID: <CA+HiwqHwV3taJ7562mD6f=0drnsGo4kE4xJQV+wW4r6C5fSEMA@mail.gmail.com>
Subject: Re: generic plans and "initial" pruning
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tomas Vondra <tomas@vondra.me>, Robert Haas <robertmhaas@gmail.com>, 
	Alvaro Herrera <alvherre@alvh.no-ip.org>, Andres Freund <andres@anarazel.de>, 
	Daniel Gustafsson <daniel@yesql.se>, David Rowley <dgrowleyml@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Thom Brown <thom@linux.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BHiwqHwV3taJ7562mD6f%3D0drnsGo4kE4xJQV%2BwW4r6C5fSEMA%40mail.gmail.com>
Precedence: bulk

On Sat, Feb 22, 2025 at 11:13=E2=80=AFAM Amit Langote <amitlangote09@gmail.=
com> wrote:
> On Sat, Feb 22, 2025 at 12:55=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wro=
te:
> > Amit Langote <amitlangote09@gmail.com> writes:
> > > The short of it is that the cached-plan-inval test in the
> > > delay_execution suite can never be made to work under
> > > CLOBBER_CACHE_ALWAYS. The test assumes that locks on partitions for a
> > > reused generic plan are not taken until InitPlan(). However, under
> > > CLOBBER_CACHE_ALWAYS, generic plans are never reused, so the test's
> > > assumption never holds.
> >
> > Ugh.
> >
> > > I see two possible ways to address this:
> >
> > > 1. Find a way to disable the cached-plan-inval test in
> > > CLOBBER_CACHE_ALWAYS builds. However, I haven't found any other test
> > > that does this.
> >
> > > 2. Remove the test altogether, though that might be too drastic.
> >
> > Well, you could force matters with "set debug_discard_caches =3D 0"
> > within the test, but I think that's just a band-aid that would
> > not make the test fully stable.  The point of CLOBBER_CACHE_ALWAYS
> > is to model random arrival of cache flush events, which is *always*
> > a possibility due to background activity (autovacuum for instance).
> >
> > We do have a couple of other regression tests that rely on
> > "set debug_discard_caches =3D 0", and I've not seen many buildfarm
> > failures tracing to that, but I don't trust it a whole lot.
> >
> > How badly do you want to keep this test case?  It seems fairly
> > rickety to me, even without this particular concern.
>
> Hmm, yeah, I have to admit that even if we address this specific
> issue, the risk of this test failing again outweighs the likelihood of
> it catching a real breakage in the deferred lock mechanism.
>
> I'll remove the test for now.

Done. I'll try to think of a more robust testing approach for this,
but I=E2=80=99m not very optimistic :-(.

--=20
Thanks, Amit Langote