From: | Dong Wook Lee <sh95119(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Subject: | Re: Add test of pg_prewarm extenion |
Date: | 2022-08-01 06:27:54 |
Message-ID: | CAAcByaKa8hyTAy_Jk-42Snmmixr80b4_KGK=QpYr+yTTbg5-zw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
First of all, thank you for your feedback.
2022년 7월 31일 (일) 오전 3:25, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>님이 작성:
>
> Justin Pryzby <pryzby(at)telsasoft(dot)com> writes:
> > On Wed, Jun 29, 2022 at 02:38:12PM +0900, Dong Wook Lee wrote:
> >> I wrote a test for pg_prewarm extension. and I wrote it with the aim of improving test coverage, and feedback is always welcome.
>
> > The test fails when USE_PREFETCH isn't defined.
> > You can accommodate that by adding an "alternate" output file, named like
> > pg_prewarm_0.out
>
> FWIW, I'd tend to just not bother exercising the prefetch case.
> It doesn't seem worth maintaining an alternate expected-file for that,
> since it's not meaningfully different from the other code paths
> as far as this code is concerned, and testing PrefetchBuffer itself
> isn't the responsibility of this test.
>
> I tried this patch locally and was disturbed to see that the
> code coverage of autoprewarm.c is still very low. It looks like
> apw_load_buffers never reaches any of the actual prewarming code,
> because it never successfully opens AUTOPREWARM_FILE. This seems a
> bit odd to me, but maybe it's because you start and immediately stop
> the database without causing it to do anything that would populate
> shared buffers? This bit:
>
> +ok ($logfile =~
> + qr/autoprewarm successfully prewarmed 0 of 1 previously-loaded blocks/);
>
> is certainly a red flag that little of interest happened.
I think it was because I didn't have much data either.
After adding data, coverage increased significantly. (11.6% -> 73.6%)
>
> Keep in mind also that the logfile accumulates over stops and
> restarts. As you've coded this test, you don't know which DB start
> emitted the matching line, so the test proves a lot less than it
> ought to.
>
> I wonder also about race conditions. On fast machines, or those
> with weird schedulers, the test script might reach slurp_file
> before autoprewarm has had a chance to emit the log entry you want.
I have no idea how to deal with race conditions.
Does anybody know how to deal with this?
Attachment | Content-Type | Size |
---|---|---|
Screen Shot 2022-08-01 at 11.59.41.png | image/png | 2.1 MB |
v2_add_test_pg_prewarm.patch | application/octet-stream | 2.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2022-08-01 07:57:44 | Re: Oversight in slab.c SlabContextCreate(), initial memory allocation size is not populated to context->mem_allocated |
Previous Message | Pavel Stehule | 2022-08-01 06:24:14 | Re: Schema variables - new implementation for Postgres 15 |