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