Re: Add test of pg_prewarm extenion
От | Dong Wook Lee |
---|---|
Тема | Re: Add test of pg_prewarm extenion |
Дата | |
Msg-id | CAAcByaKa8hyTAy_Jk-42Snmmixr80b4_KGK=QpYr+yTTbg5-zw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add test of pg_prewarm extenion (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Add test of pg_prewarm extenion
|
Список | 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?
Вложения
В списке pgsql-hackers по дате отправления: