On 2015/08/08 22:32, Robert Haas wrote:
On Sat, Aug 8, 2015 at 5:00 AM, Satoshi Nagayasu <sn...@uptime.jp> wrote:
I just found that pg_stat_statements causes assert when queryId is
set by other module, which is loaded prior to pg_stat_statements in
the shared_preload_libraries parameter.
Theoretically, queryId in the shared memory could be set by other
module by design.
So, IMHO, pg_stat_statements should not cause assert even if queryId
already has non-zero value --- my module has this problem now.
Is my understanding correct? Any comments?
Seems like an ERROR would be more appropriate than an Assert.
Well, it's not that simple, and I'm afraid that it may not fix
the issue.
Here, let's assume that we have two modules (foo and pg_stat_statements)
which calculate, use and store Query->queryId independently.
What we may see when two are enabled is following.
(1) Enable two modules in shared_preload_libraries.
shared_preload_libraries = 'foo,pg_stat_statements'
(2) Once a query comes in, a callback function in module "foo"
associated with post_parse_analyze_hook calculates and store
queryId in Query->queryId.
(3) After that, a callback function (pgss_post_parse_analyze) in
"pg_stat_statements" associated with post_parse_analyze_hook
detects that Query->queryId has non-zero value, and asserts it.
As a result, we can not have two or more modules that use queryId
at the same time.
But I think it should be possible because one of the advantages of
PostgreSQL is its extensibility.
So, I think the problem here is the fact that pg_stat_statements
deals with having non-zero value in queryId as "error" even if
it has exact the same value with other module.
Regards,
--
NAGAYASU Satoshi <sn...@uptime.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
