From: Tom Lane <tgl@sss.pgh.pa.us>
To: mike.adelson314@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16988: Spurious "SET LOCAL can only be used in transaction
 blocks" warning using implicit transaction block
In-reply-to: <16988-58edba102adb5128@postgresql.org>
References: <16988-58edba102adb5128@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Thu, 29 Apr 2021 10:49:15 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3044771.1619712195.1@sss.pgh.pa.us>
Date: Thu, 29 Apr 2021 12:03:15 -0400
Message-ID: <3044772.1619712195@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3044772.1619712195%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> I am using SET LOCAL in an Npgsql multi-statement command. It behaves as I
> expect: the scope extends to the end of the implicit transaction block for
> that command. However, each time I do this, I get a WARNING log in the
> Postgres log file: "WARNING:  SET LOCAL can only be used in transaction
> blocks". This results in a lot of log file "spam".
> Having followed up with the Npgsql team
> (https://github.com/npgsql/npgsql/issues/3688), it seems like SET LOCAL is
> behaving exactly as expected but we don't understand why the warning is
> triggering.

Hm, this seems to work as expected in psql:

regression=# set local work_mem = 100; show work_mem;
WARNING:  SET LOCAL can only be used in transaction blocks
SET
 work_mem 
----------
 4MB
(1 row)

regression=# set local work_mem = 100\; show work_mem;
 work_mem 
----------
 100kB
(1 row)

(The backslash prevents psql from treating the first semicolon
as a command separator, so that it'll send both commands in
one PQexec.)

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.

You could perhaps investigate for yourself by setting
"log_statement = all" and then seeing how the log trace for
the Npgsql fragment differs from doing the same things in psql.

			regards, tom lane