On Thu, 22 Feb 2024 at 13:01, Michael Zhilin <m.zhi...@postgrespro.ru> wrote: > I would like to say this document states that "at completion... frontend > should issue a Sync message... causes the backend to close the current > transaction" > It looks like the sense of wording is "to complete transaction" at the > eventual end of traffic, but not "to switch to single protocol". > Otherwise, we can't use both protocols under same transaction that looks too > strict limitation.
Sync only closes the current transaction when you didn't explicitly open one, i.e. you're using an implicit transaction (part of t. If you open an explicit transaction (, then you can use both extended and simple protocol messages in the same transaction. The way I understand it is: Multiple extended messages together form a single pipeline (easier understood as SQL statement), until a Sync is reached. So Parse-Bind-Execute-Parse-Bind-Execute-Sync counts as a single unit from postgres its visibility/rollback behaviour standpoint. And that's also where sending a Query instead of a Sync introduces a problem: What is supposed to happen if something fails. Let's take the simple example Bind-Execute-Query: If the Execute causes an error, is the Query still executed or not? And what about if the Query fails, is the Execute before committed or rolled back? That's why we have the Sync messages, clarify what happens when a failure occurs somewhere in the pipeline. And only extended protocol messages are allowed to be part of a pipeline: "Use of the extended query protocol allows pipelining"