To: Steve Crawford <scrawford@pinpointresearch.com>
Cc: pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org
Subject: Re: More thoughts about FE/BE protocol 
In-reply-to: <20030410155501.98D6C103C9@polaris.pinpointresearch.com> 
References: <10478.1049927451@sss.pgh.pa.us>
	<20030410155501.98D6C103C9@polaris.pinpointresearch.com>
Comments: In-reply-to Steve Crawford <scrawford@pinpointresearch.com>
	message dated "Thu, 10 Apr 2003 07:55:01 -0800"
Date: Thu, 10 Apr 2003 12:38:46 -0400
Message-ID: <4809.1049992726@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Steve Crawford <scrawford@pinpointresearch.com> writes:
> What would be the recovery/re-sync mechanism for those cases where the 
> message is, either accidentally or maliciously, longer or shorter than the 
> described length?

Once you're out of sync, there's not much to do except abandon the
connection.  The detection mechanism for this would have two parts:
(a) noticing an invalid message type code; (b) some kind of sanity
check on the message length field.  Also, if we insist that the internal
layout of each message still permits detection of the end (eg, we still
use null-terminated strings and so on), we could test for bytes being
left over in the byte count.

> Without proper timeout/recovery mechanisms a too-short message could cause 
> the receiver to effectively hang.

I see no need to try to solve the Byzantine-generals problem here.
A malicious attacker who's been able to connect to your database can
do lots worse damage than just make the backend hang up.

In the years I've been working with Postgres, I've never seen an
out-of-sync problem that didn't arise directly from the lack-of-error-
recovery deficiencies that this proposal addresses.  I don't see any
point in complicating the protocol still further to handle failures that
don't arise in practice.

			regards, tom lane