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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
