Re: Add test of pg_prewarm extenion

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Dong Wook Lee <sh95119(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add test of pg_prewarm extenion
Date: 2022-07-30 18:25:52
Message-ID: 551565.1659205552@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matheus Alcantara 2022-07-30 18:55:51 Re: Trying to add more tests to gistbuild.c
Previous Message Tom Lane 2022-07-30 17:15:04 Re: Problem about postponing gathering partial paths for topmost scan/join rel