Re: When extended query protocol ends? - Mailing list pgsql-hackers

From Jelte Fennema-Nio
Subject Re: When extended query protocol ends?
Date
Msg-id CAGECzQSEeZMR+hc9+tM+iGeOxWEx53VB0WKLyx1EOjt_y=NAKg@mail.gmail.com
Whole thread Raw
In response to Re: When extended query protocol ends?  (Michael Zhilin <m.zhilin@postgrespro.ru>)
Responses Re: When extended query protocol ends?
List 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 by date:

Previous
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Synchronizing slots from primary to standby
Next
From: Давыдов Виталий
Date:
Subject: Slow catchup of 2PC (twophase) transactions on replica in LR