Re: Add test of pg_prewarm extenion - Mailing list pgsql-hackers

From Dong Wook Lee
Subject Re: Add test of pg_prewarm extenion
Date
Msg-id CAAcByaKa8hyTAy_Jk-42Snmmixr80b4_KGK=QpYr+yTTbg5-zw@mail.gmail.com
Whole thread Raw
In response to Re: Add test of pg_prewarm extenion  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Add test of pg_prewarm extenion
List pgsql-hackers
Hi,
First of all, thank you for your feedback.

2022년 7월 31일 (일) 오전 3:25, Tom Lane <tgl@sss.pgh.pa.us>님이 작성:
>
> Justin Pryzby <pryzby@telsasoft.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
alwayswelcome. 
>
> > 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

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Schema variables - new implementation for Postgres 15
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Oversight in slab.c SlabContextCreate(), initial memory allocation size is not populated to context->mem_allocated