Dave Cramer <pg@fastcrypt.com> writes:
> More questions....
> Feb 21 10:22:52 db02a postgres[31111]: [742-1]
> user=mocospace_user,db=jnj LOG: duration: 0.088 ms execute S_3:
> select * from user_profile
> ,user_profile_access where
> Feb 21 10:22:52 db02a postgres[31111]: [742-2]
> user_profile.uid=user_profile_access.uid and user_profile.uid=$1 and
> isactive=$2
> Feb 21 10:22:52 db02a postgres[31111]: [742-3]
> user=mocospace_user,db=jnj DETAIL: parameters: $1 = '1450984', $2 = 't'
> Feb 21 10:22:52 db02a postgres[31111]: [743-1]
> user=mocospace_user,db=jnj ERROR: insufficient data left in message
> Feb 21 10:22:52 db02a postgres[31111]: [743-2]
> user=mocospace_user,db=jnj STATEMENT: select * from
> user_profile,user_profile_access where
> Feb 21 10:22:52 db02a postgres[31111]: [743-3]
> user_profile.uid=user_profile_access.uid and user_profile.uid=$1 and
> isactive=$2
> 12:25Feb 21 10:22:52 db02a postgres[31111]: [744-1]
> user=mocospace_user,db=jnj FATAL: invalid frontend message type 105
> Is this all the same error, just logged twice or is this two
> connections instances ?
AFAICT this must be two successive executions of the same prepared
query. The STATEMENT: detail attached to message 743 would have
to have come from debug_query_string, but that gets reset immediately
after emitting the "duration" message in exec_execute_message, so it
couldn't be from the same execution that resulted in message 742.
So I'm guessing that what you are seeing is a failure during parsing
of a Bind message for a fresh execution, after the spot where it
sets debug_query_string --- so the statement name is good, and the
problem seems to be in the parameters part of the message.
regards, tom lane