What does "\o /dev/null" have to do with this? That's a psql-side operation.
This is a set of commands for psql, and I use \o /dev/null to prevent SELECT results from being printed to the screen. This is unrelated to the problem.
The use of sleep does indicate awareness of the async nature of this.
Correct. Pg_sleep is used to achieve a consistently reproducible result when executing a script.
The same result (creating temporary files in different tablespaces) can be achieved by executing the specified commands manually without use of pg_sleep.
There is something odd here. Look at the log entry at 12:04:08.016; it uses base/ while the surrounding ones use pg_tblspace/ and the setting itself hasn’t changed during the sequence.
Absolutely correct. Furthermore, each execution of SELECT pg_reload_conf() will cause the next query to create temporary files in base/ once, regardless of the temp_tablespaces value. Try running the above commands manually and reviewing the logs; you'll see what I mean
On Wednesday, March 25, 2026, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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.
The use of sleep does indicate awareness of the async nature of this.
> 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.
The comment applies to all three lines in the following block, not just the first line.
There is something odd here. Look at the log entry at 12:04:08.016; it uses base/ while the surrounding ones use pg_tblspace/ and the setting itself hasn’t changed during the sequence.
I haven’t tried to validate the cursor claim yet but; this definitely isn’t the easiest format to consume and I can’t do much on my own presently.
David J.
