Re: When extended query protocol ends?
От | Jelte Fennema-Nio |
---|---|
Тема | Re: When extended query protocol ends? |
Дата | |
Msg-id | CAGECzQSEeZMR+hc9+tM+iGeOxWEx53VB0WKLyx1EOjt_y=NAKg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: When extended query protocol ends? (Michael Zhilin <m.zhilin@postgrespro.ru>) |
Ответы |
Re: When extended query protocol ends?
|
Список | pgsql-hackers |
On Thu, 22 Feb 2024 at 13:01, Michael Zhilin <m.zhilin@postgrespro.ru> wrote: > I would like to say this document states that "at completion... frontend should issue a Sync message... causes the backendto 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 singleprotocol". > 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"
В списке pgsql-hackers по дате отправления: