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.
Attachments:
0001_add_test_pg_buffercache.patchapplication/octet-stream; name=0001_add_test_pg_buffercache.patchDownload+19-0
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.
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>님이 작성:
Show quoted text
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.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>님이 작성:
Show quoted text
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