On 2015/08/08 22:32, Robert Haas wrote:
> On Sat, Aug 8, 2015 at 5:00 AM, Satoshi Nagayasu <snaga@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
andstore 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 <snaga@uptime.jp>
