Re: [HACKERS] More thoughts about FE/BE protocol

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] More thoughts about FE/BE protocol
Дата
Msg-id 5015.1049993977@sss.pgh.pa.us
обсуждение исходный текст
Ответ на More thoughts about FE/BE protocol  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] More thoughts about FE/BE protocol
Список pgsql-interfaces
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



В списке pgsql-interfaces по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] More thoughts about FE/BE protocol
Следующее
От: Michael Meskes
Дата:
Сообщение: Re: ECPG thread-safety