Re: BUG #13490: Segmentation fault on pg_stat_activity
От | Michael Bommarito |
---|---|
Тема | Re: BUG #13490: Segmentation fault on pg_stat_activity |
Дата | |
Msg-id | CAN=rtBiLm26cW13T3z-bHdL3sehPYUPXU3mdZ9iohBswwtc8+w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #13490: Segmentation fault on pg_stat_activity (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #13490: Segmentation fault on pg_stat_activity
|
Список | pgsql-bugs |
This particular instance is from pghero, which is a monitoring tool. It can be reproduced simply by querying stat_activity in psql as well. Pghero is using prepared statements via ruby from a quick skim on their github repo. We have pg_stat_statements enabled, and can reproduce without pghero setup as well. No other extensions loaded. On Jul 12, 2015 2:37 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: > Michael Bommarito <michael@bommaritollc.com> writes: > > Here's the session with debug_query_string: > > (gdb) printf "%s\n", debug_query_string > > SELECT application_name AS source, client_addr AS ip, COUNT(*) AS > > total_connections FROM pg_stat_activity WHERE pid <> pg_backend_pid() > GROUP > > BY application_name, ip ORDER BY COUNT(*) DESC, application_name ASC, > > client_addr ASC > > Thanks. This still doesn't match the stack trace: in particular, this > stack frame > > #3 0x00007fd0d478152c in expression_tree_mutator (node=0x7fd0d5d9e908, > mutator=0x7fd0d481c390 <replace_rte_variables_mutator>, > context=0x7fff52170620) at > > /tmp/buildd/postgresql-9.5-9.5~alpha1/build/../src/backend/nodes/nodeFuncs.c:2769 > > indicates that we found a PlaceHolderInfo node in the expression tree that > pullup_replace_vars() was applied to, but so far as I can see no such node > should exist in the query tree generated by this query. The most likely > theory seems to be that something clobbered the query tree while it was > sitting in the plancache, causing this recursive function to follow a > bogus pointer. But that doesn't leave us with a lot to go on. > > What can you tell us about the environment this is happening in? > How is the client-side code executing the failing queries? (We know > it's using extended query protocol, but is it preparing a statement > and then executing it repeatedly, or just using a one-shot unnamed > prepared statement?) What nondefault settings are in use on the > server side? Do you have any extensions loaded, such as > pg_stat_statements or auto_explain? > > regards, tom lane >
В списке pgsql-bugs по дате отправления: