Обсуждение: pg_buffercache: add sql test
Hi, hackers I just wrote a test code for the `pg_buffercache` extension which doesn't not have test code. I wrote the sql query to ensure that the buffer cache results are the same when `make installcheck` is performed. --- regards Lee Dong Wook.
Вложения
> On 6 Jun 2022, at 15:30, Dong Wook Lee <sh95119@gmail.com> wrote: > I just wrote a test code for the `pg_buffercache` extension which > doesn't not have test code. Please add this patch to the next commitfest to make sure it's not lost before then. https://commitfest.postgresql.org/38/ -- Daniel Gustafsson https://vmware.com/
Greetings, * Daniel Gustafsson (daniel@yesql.se) wrote: > > On 6 Jun 2022, at 15:30, Dong Wook Lee <sh95119@gmail.com> wrote: > > > I just wrote a test code for the `pg_buffercache` extension which > > doesn't not have test code. > > Please add this patch to the next commitfest to make sure it's not lost before > then. > > https://commitfest.postgresql.org/38/ Seems to be there now, at least: https://commitfest.postgresql.org/38/3674/ However, I don't think we should have a 'target version' set for this (and in particular it shouldn't be 15). I'd suggest removing that. Thanks, Stephen
I removed it on your advice. Thanks. 2022년 6월 7일 (화) 오전 2:04, Stephen Frost <stephen@crunchydata.com>님이 작성: > > Greetings, > > * Daniel Gustafsson (daniel@yesql.se) wrote: > > > On 6 Jun 2022, at 15:30, Dong Wook Lee <sh95119@gmail.com> wrote: > > > > > I just wrote a test code for the `pg_buffercache` extension which > > > doesn't not have test code. > > > > Please add this patch to the next commitfest to make sure it's not lost before > > then. > > > > https://commitfest.postgresql.org/38/ > > Seems to be there now, at least: > > https://commitfest.postgresql.org/38/3674/ > > However, I don't think we should have a 'target version' set for this > (and in particular it shouldn't be 15). I'd suggest removing that. > > Thanks, > > Stephen
Dong Wook Lee <sh95119@gmail.com> writes: > I just wrote a test code for the `pg_buffercache` extension which > doesn't not have test code. Pushed with minor adjustments. Some notes: * A .gitignore file is needed so that "git status" won't whine after running the test. This tends to be pretty much boilerplate; I copied it from another contrib directory. * Pay attention to "git diff --check" formatting warnings. In this case it bleated about an extra blank line at the end of the .sql file. * I didn't care for the direct use of pg_show_all_settings(). The official API there is the pg_settings view, and there's no need for this test to get friendly with the view's internals. Thanks for the patch! regards, tom lane
On Sun, Jul 31, 2022 at 3:39 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > * A .gitignore file is needed so that "git status" won't whine after > running the test. This tends to be pretty much boilerplate; I copied > it from another contrib directory. Is there any reason we don't add a .gitignore in the contrib/ directory to ignore all */log/, */results/ and */tmp_check/ by default rather having at least /log/, /results/ and /tmp_check/ in almost all subdirectories .gitignore? Sure any underlying "(log|results|tmp_check)" top-directory will then be ignored even if it's not supposed to be needed, but I don't think it would matter in practice. And if it does matter you could still force some file to be included or even override the parent gitignore.
I've been missing what I have to add to the .gitignore file when I write the test. I will refer to it when I write the test code from now on. Thank you. 2022년 7월 31일 (일) 오전 4:39, Tom Lane <tgl@sss.pgh.pa.us>님이 작성: > > Dong Wook Lee <sh95119@gmail.com> writes: > > I just wrote a test code for the `pg_buffercache` extension which > > doesn't not have test code. > > Pushed with minor adjustments. Some notes: > > * A .gitignore file is needed so that "git status" won't whine after > running the test. This tends to be pretty much boilerplate; I copied > it from another contrib directory. > > * Pay attention to "git diff --check" formatting warnings. In this > case it bleated about an extra blank line at the end of the .sql file. > > * I didn't care for the direct use of pg_show_all_settings(). The > official API there is the pg_settings view, and there's no need for > this test to get friendly with the view's internals. > > Thanks for the patch! > > regards, tom lane