Re: generic plans and "initial" pruning

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(at)vondra(dot)me>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Daniel Gustafsson <daniel(at)yesql(dot)se>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Thom Brown <thom(at)linux(dot)com>
Subject: Re: generic plans and "initial" pruning
Date: 2025-02-21 15:55:03
Message-ID: 3132441.1740153303@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Langote <amitlangote09(at)gmail(dot)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 = 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 = 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2025-02-21 16:04:49 Re: TAP test started using meson, can get a tcp port already used by another test.
Previous Message Andres Freund 2025-02-21 15:50:14 Re: TAP test started using meson, can get a tcp port already used by another test.