extended query protcol violation?

Поиск
Список
Период
Сортировка
От Tatsuo Ishii
Тема extended query protcol violation?
Дата
Msg-id 20181208.104532.581384323124734931.t-ishii@sraoss.co.jp
обсуждение исходный текст
Ответы Re: extended query protcol violation?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
While looking into an issue of Pgpool-II, I found an interesting
behavior of a PostgreSQL client.
Below is a trace from pgproto to reproduce the client's behavior.

It starts a transacton.

FE=> Parse(stmt="S1", query="BEGIN")
FE=> Bind(stmt="S1", portal="")
FE=> Execute(portal="")
:
Commit the transaction

FE=> Parse(stmt="S1", query="COMMIT")
FE=> Bind(stmt="S1", portal="")
FE=> Execute(portal="")

Send sync message.

FE=> Sync

Now the interesting part. After sync it a close message is sent.

FE=> Close(stmt="S1")

Then issues a simple query.

FE=> Query (query="BEGIN")

I thought all extended query protocol messages are finished by a sync
message. But in the example above, a close message is issued, followed
by a simple query without a sync message. Should PostgreSQL regard
this as a protocol violation?

From our documents regarding the extended query protocol, I assume
close message is a part of extended query protocol.

https://www.postgresql.org/docs/11/protocol-flow.html#PROTOCOL-FLOW-EXT-QUERY

"At completion of each series of extended-query messages, the frontend
should issue a Sync message."
:
"In addition to these fundamental, required operations, there are
several optional operations that can be used with extended-query
protocol."
:
"The Close message closes an existing prepared statement or portal and
releases resources"

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp


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

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: [HACKERS] Bug when dumping "empty" operator classes
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: Connections hang indefinitely while taking a gin index's LWLockbuffer_content lock