Re: Add test of pg_prewarm extenion

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

In response to

Responses

Browse pgsql-hackers by date

  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