Re: RFC: Logging plan of the running query

From: torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Atsushi Torikoshi <torikoshia(dot)tech(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, samimseih(at)gmail(dot)com, destrex271(at)gmail(dot)com
Subject: Re: RFC: Logging plan of the running query
Date: 2025-11-25 12:43:46
Message-ID: 900f24c08ea77d4ca6871c39e2b898d3@oss.nttdata.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2025-11-20 22:17, Robert Haas wrote:
> On Wed, Nov 19, 2025 at 8:52 PM torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>
> wrote:
>> I think it's possible.
>> Updated the test so that COMMIT happens only after we confirm that the
>> backend is already waiting at the injection point.
>
> Thanks, that looks better to me. Looking at this version, I wondered
> whether this was OK:
>
> +# Commit the session 2 to release the advisory lock.
> +$psql_session2->query_safe("COMMIT;");
> +
> +my $log_offset = -s $node->logfile;
>
> If the COMMIT causes something to appear in the log, we're not
> guaranteed as to whether that will happen before or after we record
> the log offset. However, the string for which we're looking will (if I
> understand correctly) only appear after the wakeup/detach from the
> injection point, so I don't think there's any real problem here.

I have the same understanding.

> A couple of testing suggestions, if you haven't already:

Thank you for the suggestions.

> 1. Run the test in a loop, say 100 times, to check for random failures.

I ran 010_pg_log_query_plan.pl 300 times, but it never failed.

> 2. Insert a sleep(10) after each line of the strict in turn and run it
> (perhaps a few tiimes) and check to make sure that the tests still
> pass. (I don't mean put sleep(10) after every line -- I mean put a
> sleep(10) in one place at a time and keep moving it after you've
> verified that the current location doesn't cause a failure.)

I inserted sleep(10) at each line in turn and ran the test 10 times for
each location, but fortunately (or unfortunately?) I did not observe any
failures.

> I know from experience that it's quite hard to get these tests to be
> fully reliable and I won't feel too bad if it turns out we missed
> something, but at least we can try.

BTW to test not 010_pg_log_query_plan but pg_log_query_plan(), I also
invoked pg_log_query_plan() in 3 parallel sessions at 0.1-second
intervals(\watch 0.1) during running `make intallcheck` 10 times, and I
did not see any crashes.

--
Regards,

--
Atsushi Torikoshi
Seconded from NTT DATA Japan Corporation to SRA OSS K.K.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dagfinn Ilmari Mannsåker 2025-11-25 12:59:07 Re: Some optimizations for COALESCE expressions during constant folding
Previous Message David Rowley 2025-11-25 12:36:52 Re: Partial hash index is not used for implied qual.