| From: | Dmitriy Kuzmin <kuzmin(dot)db4(at)gmail(dot)com> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #19437: temp_tablespaces doesn't work inside a cursor? |
| Date: | 2026-03-25 14:30:38 |
| Message-ID: | CA+TefFDrwAppW33A6Y4Cz1f6Zf11bS3+DOqerx8JCnGspg9xKA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
>
> 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
ср, 25 мар. 2026 г. в 23:52, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>:
> On Wednesday, March 25, 2026, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> PG Bug reporting form <noreply(at)postgresql(dot)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.
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | surya poondla | 2026-03-25 22:45:11 | Re: Two issues with REFRESH MATERIALIZED VIEW CONCURRENTLY |
| Previous Message | PG Bug reporting form | 2026-03-25 14:06:37 | BUG #19439: pg_stat_xact_user_tables stat not currect during the transaction |