Horton

Re: Weird test mixup

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-03-14T22:53:57Z
Lists: pgsql-hackers 
On Thu, Mar 14, 2024 at 06:19:38PM -0400, Tom Lane wrote:
> Do they?  It'd be fairly easy to explain this if these things were
> being run in "installcheck" style.  I'm not sure about CI, but from
> memory, the buildfarm does use installcheck for some things.
> 
> I wonder if it'd be wise to adjust the injection point stuff so that
> it's active in only the specific database the injection point was
> activated in.

It can be made optional by extending InjectionPointAttach() to
specify a database OID or a database name.  Note that
041_checkpoint_at_promote.pl wants an injection point to run in the
checkpointer, where we don't have a database requirement.

Or we could just disable runningcheck because of the concurrency
requirement in this test.  The test would still be able to run, just
less times.
--
Michael

Commits

  1. injection_points: Store runtime conditions in private area

  2. Introduce private data area for injection points

  3. injection_points: Fix incorrect spinlock acquisition

  4. Make GIN tests using injection points concurrent-safe

  5. injection_points: Fix race condition with local injection point tests

  6. injection_points: Introduce runtime conditions

  7. Make GIN test using injection points repeatable

  8. Fix backstop in gin test if injection point is not reached

  9. Try to unbreak injection-fault tests in the buildfarm

  10. Disable tests using injection points in installcheck