public inbox for [email protected]help / color / mirror / Atom feed
When extended query protocol ends? 3+ messages / 2 participants [nested] [flat]
* When extended query protocol ends? @ 2024-01-29 23:22 Tatsuo Ishii <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Tatsuo Ishii @ 2024-01-29 23:22 UTC (permalink / raw) To: pgsql-hackers While taking care of a Pgpool-II trouble report from user [1], I found an interesting usage pattern of the extended query protocol. In my understanding a series of queries in the extended query protocol is ended by a sync message. Then one ReadyForQuery response comes for one sync message. However this does not apply if simple query message is sent instead of sync. Below is outputs from "pgproto" command coming with Pgpool-II. (Lines starting "FE" represents a message from frontend to backend. Lines starting "BE" represents a message from backend to frontend.) FE=> Parse(stmt="", query="SET extra_float_digits = 3") FE=> Bind(stmt="", portal="") FE=> Execute(portal="") FE=> Parse(stmt="", query="SET extra_float_digits = 3") FE=> Bind(stmt="", portal="") FE=> Execute(portal="") FE=> Query (query="SET extra_float_digits = 3") <= BE ParseComplete <= BE BindComplete <= BE CommandComplete(SET) <= BE ParseComplete <= BE BindComplete <= BE CommandComplete(SET) <= BE CommandComplete(SET) <= BE ReadyForQuery(I) FE=> Terminate As you can see, two "SET extra_float_digits = 3" is sent in the extended query protocol, then one "SET extra_float_digits = 3" follows in the simple query protocol. No sync message is sent. However, I get ReadyForQuery at the end. It seems the extended query protocol is ended by a simple query protocol message instead of a sync message. My question is, is this legal in terms of fronted/backend protocol? If it's legal, I think we'd better to explicitly mention in our document. Otherwise, users may be confused. For example, in "55.2.4. Pipelining": "When using this method, completion of the pipeline must be determined by counting ReadyForQuery messages and waiting for that to reach the number of Syncs sent." Apparently this does not apply to the above example because there's 0 sync message. Best reagards, [1] https://www.pgpool.net/pipermail/pgpool-general/2023-December/009051.html -- Tatsuo Ishii SRA OSS LLC English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: When extended query protocol ends? @ 2024-01-29 23:40 Tom Lane <[email protected]> parent: Tatsuo Ishii <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Tom Lane @ 2024-01-29 23:40 UTC (permalink / raw) To: Tatsuo Ishii <[email protected]>; +Cc: pgsql-hackers Tatsuo Ishii <[email protected]> writes: > Below is outputs from "pgproto" command coming with Pgpool-II. > (Lines starting "FE" represents a message from frontend to backend. > Lines starting "BE" represents a message from backend to frontend.) > FE=> Parse(stmt="", query="SET extra_float_digits = 3") > FE=> Bind(stmt="", portal="") > FE=> Execute(portal="") > FE=> Parse(stmt="", query="SET extra_float_digits = 3") > FE=> Bind(stmt="", portal="") > FE=> Execute(portal="") > FE=> Query (query="SET extra_float_digits = 3") > <= BE ParseComplete > <= BE BindComplete > <= BE CommandComplete(SET) > <= BE ParseComplete > <= BE BindComplete > <= BE CommandComplete(SET) > <= BE CommandComplete(SET) > <= BE ReadyForQuery(I) > FE=> Terminate > As you can see, two "SET extra_float_digits = 3" is sent in the > extended query protocol, then one "SET extra_float_digits = 3" follows > in the simple query protocol. No sync message is sent. However, I get > ReadyForQuery at the end. It seems the extended query protocol is > ended by a simple query protocol message instead of a sync message. > My question is, is this legal in terms of fronted/backend protocol? I think it's poor practice, at best. You should end the extended-protocol query cycle before invoking simple query. I'm disinclined to document, or make any promises about, what happens if you mix the protocols. regards, tom lane ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: When extended query protocol ends? @ 2024-01-30 01:15 Tatsuo Ishii <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Tatsuo Ishii @ 2024-01-30 01:15 UTC (permalink / raw) To: [email protected]; +Cc: [email protected]; pgsql-hackers Hello Dave, > Tatsuo Ishii <[email protected]> writes: >> Below is outputs from "pgproto" command coming with Pgpool-II. >> (Lines starting "FE" represents a message from frontend to backend. >> Lines starting "BE" represents a message from backend to frontend.) > >> FE=> Parse(stmt="", query="SET extra_float_digits = 3") >> FE=> Bind(stmt="", portal="") >> FE=> Execute(portal="") >> FE=> Parse(stmt="", query="SET extra_float_digits = 3") >> FE=> Bind(stmt="", portal="") >> FE=> Execute(portal="") >> FE=> Query (query="SET extra_float_digits = 3") >> <= BE ParseComplete >> <= BE BindComplete >> <= BE CommandComplete(SET) >> <= BE ParseComplete >> <= BE BindComplete >> <= BE CommandComplete(SET) >> <= BE CommandComplete(SET) >> <= BE ReadyForQuery(I) >> FE=> Terminate > >> As you can see, two "SET extra_float_digits = 3" is sent in the >> extended query protocol, then one "SET extra_float_digits = 3" follows >> in the simple query protocol. No sync message is sent. However, I get >> ReadyForQuery at the end. It seems the extended query protocol is >> ended by a simple query protocol message instead of a sync message. > >> My question is, is this legal in terms of fronted/backend protocol? > > I think it's poor practice, at best. You should end the > extended-protocol query cycle before invoking simple query. ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-01-30 01:15 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-01-29 23:22 When extended query protocol ends? Tatsuo Ishii <[email protected]> 2024-01-29 23:40 ` Tom Lane <[email protected]> 2024-01-30 01:15 ` Tatsuo Ishii <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox