Re: RFC: Logging plan of the running query
| От | torikoshia |
|---|---|
| Тема | Re: RFC: Logging plan of the running query |
| Дата | |
| Msg-id | 900f24c08ea77d4ca6871c39e2b898d3@oss.nttdata.com обсуждение исходный текст |
| Ответ на | Re: RFC: Logging plan of the running query (Robert Haas <robertmhaas@gmail.com>) |
| Список | pgsql-hackers |
On 2025-11-20 22:17, Robert Haas wrote:
> On Wed, Nov 19, 2025 at 8:52 PM torikoshia <torikoshia@oss.nttdata.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.
В списке pgsql-hackers по дате отправления: