From: Tom Lane <tgl@sss.pgh.pa.us>
To: kuzmin.db4@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19437: temp_tablespaces doesn't work inside a cursor?
In-reply-to: <19437-0a65fb52d0f13a0d@postgresql.org>
References: <19437-0a65fb52d0f13a0d@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Wed, 25 Mar 2026 10:02:09 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <233967.1774445501.1@sss.pgh.pa.us>
Date: Wed, 25 Mar 2026 09:31:41 -0400
Message-ID: <233968.1774445501@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/233968.1774445501%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> I'm seeing strange behavior in Postgres when changing the temp_tablespaces
> parameter and suspect a bug. At least, I haven't found a description of this
> behavior in the documentation.

I think you are imagining that pg_reload_conf() is a synchronous
operation.  It is not.  It merely signals the postmaster process
to start a configuration reload.  After the postmaster has done
that, it in turn signals all its children to reload configuration.
If memory serves, a child process honors that signal next time
it arrives at its outer wait-for-a-command loop.  So it's not
exactly surprising if your script is able to execute a command or
three before it takes up the ALTER SYSTEM changes.  (Your log
shows that it can get through several commands before the
postmaster even gets the reload signal, let alone sends it back.)

If you want to set temp_tablespaces locally and have it take
effect immediately, just use SET.  ALTER SYSTEM is quite the
wrong tool for the job.

> Ensure that temporary files are created in it:
> \o /dev/null

What does "\o /dev/null" have to do with this?  That's a
psql-side operation.

			regards, tom lane