Subject: Re: wire protocol errors on Debian (py3/psyco 2.8)
To: Daniele Varrazzo <daniele.varrazzo@gmail.com>, psycopg@postgresql.org
References: <20200314153421.GC1104@hermes.hilbert.loc>
 <CA+mi_8Z0f=_bdBci2KtwMUbuKCoDiHQnR72pvYzF5tx1=PSB1g@mail.gmail.com>
From: Adrian Klaver <adrian.klaver@aklaver.com>
Message-ID: <adad228f-4f9f-6b82-b780-d89a1901984b@aklaver.com>
Date: Sat, 14 Mar 2020 13:29:58 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: 
 <CA+mi_8Z0f=_bdBci2KtwMUbuKCoDiHQnR72pvYzF5tx1=PSB1g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 3/14/20 12:35 PM, Daniele Varrazzo wrote:
> 
> 

> 
> The error comes from the libpq failing to parse messages from the server 
> (at a glance CommandComplete and RowDescription - see 
> https://www.postgresql.org/docs/current/protocol-message-formats.html) 
> which are probably just the most common ones.
> 
> I doubt it's a bug with libpq 12.2 or whatever server is on the other 
> side of the wire: we would have seen this error more often. If you want 
> to investigate in that direction you may ask core devs if there have 
> been changes in that area for those versions.

I did run across this:

https://www.postgresql.org/docs/12/release-12-2.html

"

Fix bugs in handling of non-blocking I/O when using GSSAPI encryption 
(Tom Lane)

These errors could result in dropping data (usually leading to 
subsequent wire-protocol-violation errors) or in a “livelock” situation 
where a sending process goes to sleep although not all its data has been 
sent. Moreover, libpq failed to keep separate encryption state for each 
connection, creating the possibility for failures in applications using 
multiple encrypted database connections.
"

Would be nice to know what actual Postgres version is and how it is 
configured?


> 
> My wild guess is either faulty network or faulty memory on the machine, 
> most likely the latter.
> 
> -- Daniele


-- 
Adrian Klaver
adrian.klaver@aklaver.com