| 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: | Whole Thread | Raw Message | 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 |