I used your example and tried it with prepared statements. I captured the traffic with Wireshark. My client sent Bind/Execute/Sync messages, and PostgreSQL 14 sent back BindComplete/CommandComplete/ErrorResponse messages, followed by ReadyForQuery after that.
So yes, it looks like ErrorResponse is a valid response for Sync. On Tue, Jan 18, 2022 at 6:11 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > On 2022-Jan-12, Andrei Matei wrote: > > > If Sync itself cannot fail, then what is this > > sentence really saying: "This parameterless message (ed. Sync) causes the > > backend to close the current transaction if it's not inside a > BEGIN/COMMIT > > transaction block (“close” meaning to commit if no error, or roll back if > > error)." ? > > This seems to say that, outside of BEGIN/END, the transaction is > committed > > at Sync time (i.e. if the Sync is never sent, nothing is committed). > > Presumably, committing a transaction can fail even if no > > previous command/statement failed, right? > > A deferred trigger can cause a failure at COMMIT time for which no > previous error was reported. > > alvherre=# create table t (a int unique deferrable initially deferred); > CREATE TABLE > alvherre=# insert into t values (1); > INSERT 0 1 > alvherre=# begin; > BEGIN > alvherre=*# insert into t values (1); > INSERT 0 1 > alvherre=*# commit; > ERROR: duplicate key value violates unique constraint "t_a_key" > DETALLE: Key (a)=(1) already exists. > > I'm not sure if you can cause this to explode with just a Sync message, > though. > > -- > Álvaro Herrera Valdivia, Chile — > https://www.EnterpriseDB.com/ > > > > >
