Re: Can can I make an injection point wait occur no more than once?

From: Noah Misch <noah(at)leadboat(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Can can I make an injection point wait occur no more than once?
Date: 2025-07-10 02:24:44
Message-ID: 20250710022444.fb.nmisch@google.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 08, 2025 at 11:43:17PM -0400, Peter Geoghegan wrote:
> On Tue, Jul 8, 2025 at 11:04 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
> > > -backwards_scan_session: NOTICE: notice triggered for injection point lock-and-validate-new-lastcurrblkno
> > > +ERROR: could not find injection point lock-and-validate-left to wake up
> >
> > Agreed. Perhaps it's getting a different plan type on FreeBSD, so it's not
> > even reaching the INJECTION_POINT() calls? That would be consistent with
> > these output diffs having no ERROR from attach/detach. Some things I'd try:
> >
> > - Add a plain elog(WARNING) before each INJECTION_POINT()
> > - Use debug_print_plan or similar to confirm the plan type
>
> I added a pair of elog(WARNING) traces before each of the new
> INJECTION_POINT() calls.
>
> When I run the test against the FreeBSD CI target with this new
> instrumentation, I see a WARNING that indicates that we've reached the
> top of _bt_lock_and_validate_left as expected. I don't see any second
> WARNING indicating that we've taken _bt_lock_and_validate_left's
> unhappy path, though (and the test still fails). This doesn't look
> like an issue with the planner.
>
> I attach the relevant regression test output, that shows all this.

Looking at .cirrus.tasks.yml, I bet the key factor is that CI task using
debug_parallel_query=regress. I bet the leader is attached to the injection
point, but the WARNING is reached in a parallel worker.

If that matches what you see, I'd use a PARALLEL RESTRICTED or PARALLEL UNSAFE
function in your query to ensure the code in question runs in the leader.
(Simply overriding debug_parallel_query is less robust, because test runs
could use other settings that cause selection of a parallel plan.)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message cca5507 2025-07-10 02:45:44 Re: Small optimization with expanding dynamic hash table
Previous Message Yugo Nagata 2025-07-10 01:30:41 Re: Extend ALTER DEFAULT PRIVILEGES for large objects