Обсуждение: invalid frontend message type 136
I got this message immediately after a connection to the server. I haven't seen it before and Googling has come up short so far. There are no other indications of trouble. Ideas or suggestions where to look? Cheers, Steve
It would help to at least know against which version of the database you are trying to connect and also what client (with version) you are using. Any other connection-related information (password based; ident; etc...) would be helpful as well. David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/invalid-frontend-message-type-136-tp5769775p5769778.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Sorry, I should have included that. The error occurred when an older client running 8.3.7 (I know, ferreting and finishing upgrades on clients with old libraries is in progress) on CentOS 5.3 (32-bit). Of all the machines connecting to the server, this one pretty lightly loaded and typically creates a new connection to the server somewhat over 10,000 times/week. This is the first instance of the error. These machines/connections are buried behind firewalls in an automated system and this particular connection is password-less. The server is PostgreSQL 9.1.9 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit. Cheers, Steve On 09/05/2013 12:04 PM, David Johnston wrote: > It would help to at least know against which version of the database you are > trying to connect and also what client (with version) you are using. Any > other connection-related information (password based; ident; etc...) would > be helpful as well. > > David J. > > > > > -- > View this message in context: http://postgresql.1045698.n5.nabble.com/invalid-frontend-message-type-136-tp5769775p5769778.html > Sent from the PostgreSQL - general mailing list archive at Nabble.com. > >
Steve Crawford wrote > Sorry, I should have included that. The error occurred when an older > client running 8.3.7 (I know, ferreting and finishing upgrades on > clients with old libraries is in progress) on CentOS 5.3 (32-bit). Of > all the machines connecting to the server, this one pretty lightly > loaded and typically creates a new connection to the server somewhat > over 10,000 times/week. This is the first instance of the error. > > These machines/connections are buried behind firewalls in an automated > system and this particular connection is password-less. > > The server is PostgreSQL 9.1.9 on x86_64-unknown-linux-gnu, compiled by > gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit. > > Cheers, > Steve > > > On 09/05/2013 12:04 PM, David Johnston wrote: >> It would help to at least know against which version of the database you >> are >> trying to connect and also what client (with version) you are using. Any >> other connection-related information (password based; ident; etc...) >> would >> be helpful as well. >> >> David J. >> >> Which client (not just the version): psql; jdbc; .net; libpq I am not surprised that an old client talking to a new server would cause a protocol error to be issued. I'm doubtful you will get much help on the mailing lists for something like this unless you are much more detailed in describing your environment and usage - at the least I am unable to provide much further help myself. On-list trouble shooting is difficult and given the version of the (unnamed) software involved likely few people will want to try. If you cannot upgrade the client driver to match the server you should at least try and enumerate what kinds of things you have changed and try and narrow down whether this is a client, server, or machine specific issue. Searching the source code for where this error is thrown (likely server but maybe client) would be a good start. Someone familiar with the codebase may be able to handle that particular request though I am not currently setup to do so. HTH David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/invalid-frontend-message-type-136-tp5769775p5770343.html Sent from the PostgreSQL - general mailing list archive at Nabble.com.
On 09/10/2013 11:30 AM, David Johnston wrote: > Steve Crawford wrote >> Sorry, I should have included that. The error occurred when an older >> client running 8.3.7 (I know, ferreting and finishing upgrades on >> clients with old libraries is in progress) on CentOS 5.3 (32-bit). Of >> all the machines connecting to the server, this one pretty lightly >> loaded and typically creates a new connection to the server somewhat >> over 10,000 times/week. This is the first instance of the error. >> >> These machines/connections are buried behind firewalls in an automated >> system and this particular connection is password-less. >> >> The server is PostgreSQL 9.1.9 on x86_64-unknown-linux-gnu, compiled by >> gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit. >> Which client (not just the version): >> >> psql; jdbc; .net; libpq Unfortunately I'm not sure. There are many interrelated process that communicate with the server and since the connection bailed on connect there isn't much info to tell me which one. So it could be psql, code in one of several C-programs or connections from Perl or other scripting program. But they are all using the same libraries. > > I am not surprised that an old client talking to a new server would cause a > protocol error to be issued. Fair enough. But this is *one* error from among millions of successful connections in a farm of similar servers. This server happens to be one from an older series that is in-line for updates but is not the only one running this version. The nature of our operation along with some very specific requirement forced by specialized underlying hardware requires careful hand-rolling of updates to the machines. > > > I'm doubtful you will get much help on the mailing lists for something like > this ... Actually, all I want to know is: 1) A definition of the error - I can research further from there. PostgreSQL has by far the most outstanding documentation of any open-source (or possibly closed-source) product I use but it still lacks in a comprehensive (i.e. any) glossary of log/error messages. 2) An idea of whether or not to worry. If it is an odd and harmless transient (dealt with automatically by our error-checking/validation/recovery code) then I'll ignore it. But if it's something that could be an early indication of lurking corruption or pending failure then I need to investigate aggressively. Cheers, Steve