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.
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.
regards, tom lane