From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brar Piening <brar(at)gmx(dot)de> |
Cc: | mike(dot)adelson314(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16988: Spurious "SET LOCAL can only be used in transaction blocks" warning using implicit transaction block |
Date: | 2021-05-01 23:35:55 |
Message-ID: | 3493686.1619912155@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Brar Piening <brar(at)gmx(dot)de> writes:
> Tom Lane wrote:
>> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
>>> I am using SET LOCAL in an Npgsql multi-statement command.
>> It seems that whatever Npgsql is doing at the wire protocol level
>> doesn't match this, but they'd have to explain what they are doing
>> for us to offer much help.
> At the wire protocol level npgsql sends this as two queries via the
> extended query protocol without a sync inbetween them.
> (Parse,Bind,Describe,Execute;Parse,Bind,Describe,Execute,Sync)
There is no implicit transaction block around the two commands in such
a case, so that explains why it doesn't act as Mike was hoping.
Omitting the Sync has zero effect on transactional semantics; it only
means that if the first command fails, we'll skip the second one.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Brar Piening | 2021-05-02 06:53:02 | Re: BUG #16988: Spurious "SET LOCAL can only be used in transaction blocks" warning using implicit transaction block |
Previous Message | Brar Piening | 2021-05-01 22:22:44 | Re: BUG #16988: Spurious "SET LOCAL can only be used in transaction blocks" warning using implicit transaction block |