From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core |
Date: | 2014-01-22 21:36:04 |
Message-ID: | CAM3SWZSoDumus=jQkRpQBhOM+QmdyhYKyPmR8-MmyLYUsxf5hQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 22, 2014 at 1:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> BTW, have you got any sort of test scenario you could share for this
> purpose? I'm sure I could build something, but if you've already
> done it ...
I simply ran the standard regression tests, and then straced a backend
as it executed the pgss-calling query. I'm not sure that I've
understood your question.
As previously noted, my approach to testing this patch involved variations of:
running "make installcheck-parallel"
Concurrently, running pgbench with multiple clients each calling
pg_stat_statements() and pg_stat_statements_reset(). The latter was
sometimes rigged to do a direct garbage collection to stress test
things. My expectation was that the sanity checking done everywhere
would complain if there were any race conditions or other bugs. This
was pretty effective as a smoke test during development.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-01-22 21:38:13 | Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core |
Previous Message | Joseph Kregloh | 2014-01-22 21:33:47 | Re: pg_upgrade & tablespaces |