Re: Add test of pg_prewarm extenion
Dong Wook Lee <sh95119@gmail.com>
From: Dong Wook Lee <sh95119@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, Justin Pryzby <pryzby@telsasoft.com>
Date: 2022-08-01T06:27:54Z
Lists: pgsql-hackers
Attachments
- Screen Shot 2022-08-01 at 11.59.41.png (image/png)
- v2_add_test_pg_prewarm.patch (application/octet-stream) patch v2
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 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?
Commits
-
Add a regression test for contrib/pg_prewarm.
- 2865b4060a43 16.0 landed