Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core
Date
Msg-id CAM3SWZSoDumus=jQkRpQBhOM+QmdyhYKyPmR8-MmyLYUsxf5hQ@mail.gmail.com
Whole thread Raw
In response to Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Jan 22, 2014 at 1:22 PM, Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PoC: Duplicate Tuple Elidation during External Sort for DISTINCT
Next
From: Tom Lane
Date:
Subject: Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core