2

Error

invalid frontend message type 74

I'm getting this error and I have no idea where it's coming from or what it means. I can't find any documentation on frontend message types in the PostgreSQL documentation.

I tried enabling the log of every statement, but this error isn't occurring after any specific statement in the log. The statements are different each time, and when run via pgsql, the statements run without error.

Is there anyway I can print out what statement or message is causing this error? I really don't know how to proceed without knowing the source.

PostgreSQL Version

PostgreSQL 9.4.5 on amd64-portbld-freebsd10.2, compiled by FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512, 64-bit
Improve this question
2
  • What client are you using?
    – JoshRagem
    Jul 29, 2016 at 10:01
  • @JoshRagem the client is a C application written with libpq.
    – quickblueblur
    Jul 29, 2016 at 10:32

1 Answer 1

Reset to default
4

I'm getting this error and I have no idea where it's coming from or what it means. I can't find any documentation on frontend message types in the PostgreSQL documentation.

They're listed here:

https://www.postgresql.org/docs/current/static/protocol-message-formats.html

and a more general description of the protocol is at:

https://www.postgresql.org/docs/current/static/protocol-overview.html#PROTOCOL-MESSAGE-CONCEPTS

The type of the message is given by the first byte. For example, if a client issues a "Bind", the first byte is the ASCII code for 'B', or 66.

The value 74 from the error message would be 'J', but according to the doc this message type is not used for anything in any version of the protocol, so the client or middleware sending it must be misbehaving.

If the traffic is not encrypted, a packet inspection tool like Wireshark might help to look into these packets. Wireshark knows about the PGSQL protocol. On the postgres server side, I don't think you can get more information beyond the mentioned error, because the backend gives up on the message at the first byte. As far as it's concerned, it's not correlated to any query.

Improve this answer
4
  • Thanks for the tips. I'll look into grabbing a Wireshark capture to see if that will help. The client is a C application using libpq so I'll try to see if anything sends a first byte as 74.
    – quickblueblur
    Jul 29, 2016 at 10:31
  • 1
    I'm marking this as the answer. I found out why it's happening with Wireshark's help. For some reason libpq is taking the stdout from the application and using it during the initial start-up. You can see the stdout in the package capture being sent to the PostgreSQL server. I'll have to look into exactly why this is occurring. The easy solution is turning off stdout, but that's just masking the problem, not really solving it.
    – quickblueblur
    Jul 29, 2016 at 14:12
  • 1
    @quickblueblur: I would suspect that the C program closes its FDs 1,2, then connects to postgresql, so the socket to PG is assigned to FD 1, which corresponds to stdout by convention.
    – Daniel Vérité
    Jul 29, 2016 at 17:23
  • 2
    You are correct. The application runs as a daemon and during the process of creating the daemon, the application closed stdin, stdout and stderr. The logging process would write to a file, but also write to stdout. Since PG took over FD 1, it was grabbing the output from the logging process.
    – quickblueblur
    Aug 1, 2016 at 13:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.