To: Hannu Krosing <hannu@tm.ee>
Cc: Peter Galbavy <peter.galbavy@knowtion.net>,
	pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org
Subject: Re: More thoughts about FE/BE protocol 
In-reply-to: <1049993435.1886.24.camel@fuji.krosing.net> 
References: <10478.1049927451@sss.pgh.pa.us>
	<003f01c2ff40$9f1a0e70$7c28a8c0@cblan.mblox.com>
	<3625.1049983061@sss.pgh.pa.us>
	<1049993435.1886.24.camel@fuji.krosing.net>
Comments: In-reply-to Hannu Krosing <hannu@tm.ee>
	message dated "10 Apr 2003 19:50:35 +0300"
Date: Thu, 10 Apr 2003 12:59:37 -0400
Message-ID: <5015.1049993977@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Hannu Krosing <hannu@tm.ee> writes:
> Tom Lane kirjutas N, 10.04.2003 kell 16:57:
>> See my response to ljb --- I think that in practice people assemble each
>> message before sending anyway. 

> I just tested it by running "select *" on 68M records (6.5 GB data)
> table and you seem to be wrong - while psql shows nothing, its size
> starts rapidly growing (I ^C it at ~500M) , while backend stays at
> stable 32M, which indicates that postgres starts to push data out as
> fast as it can get it.

Sure.  "Message" here is at the granularity of one data row, not an
entire query result.

> If you hit an error condition after sending a partial message then I'm
> in trouble anyway. Assembling the message beforehand just makes hitting
> error less likely.

But when you assemble the message beforehand, the only possible
part-way-through failures are communications failures, for which you may
as well abandon the connection anyhow.

> I would propose something like X11 protocol (from memory)

As I was saying to Steve, I don't want to complicate the protocol more
than is needed to handle the problems we have actually had.  We don't
use unreliable transport mechanisms and are not likely to start doing so
in future, so I see no need to invent features to deal with problems
that are already solved by the transport mechanism.

> Also there should be a way to tell the backend not to send some types of
> notices/warnings.

We already have that, see client_min_message_level.

			regards, tom lane