Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w5PG3-003Dic-01 for pgsql-bugs@arkaria.postgresql.org; Wed, 25 Mar 2026 14:30:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w5PG1-00EKcA-1g for pgsql-bugs@arkaria.postgresql.org; Wed, 25 Mar 2026 14:30:53 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w5PG1-00EKc2-0i for pgsql-bugs@lists.postgresql.org; Wed, 25 Mar 2026 14:30:53 +0000 Received: from mail-ot1-x336.google.com ([2607:f8b0:4864:20::336]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w5PFy-0000000154D-3hLy for pgsql-bugs@lists.postgresql.org; Wed, 25 Mar 2026 14:30:53 +0000 Received: by mail-ot1-x336.google.com with SMTP id 46e09a7af769-7d7d50516e9so3546474a34.1 for ; Wed, 25 Mar 2026 07:30:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774449049; cv=none; d=google.com; s=arc-20240605; b=L54zcFIxRuSx4ItyyJX7BpB5jcAvAzj1DOnKASiuJQLWJeYRJeexkYSx0zXzcoDJq5 sNGq6c7CdsFMKP+2n17ZQ0egC36/B58hUNwakGkAtMVecSrKI9UrcqdwrkagjDyckJWk qPCn+IWBzZPg6H3R387TJwDZ2vfld3dCYyYiGufM4VkxWSrCQf/r0nEtclx/7lz6B0yh YbktA31cq+NOWgJFhhl/V/gt1j8ZDp83mgG/L9Adx5LVxSwisWEchShbFqikHYLSSzSZ ZuRjwaI91wFJRBf9Cp73Xyda02iZyQd/Djc+h0lv6FMw1SC+KnNr6gQi9UxxvVcyOxHr RaKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=8Y1/8Y58nPSbFPF/MiBgD2IOB6UCozTdaA9cRqPPTD8=; fh=MMEGFCsEkdu5HJy4wDWq0O7TQStDtafPv55olT+WlAE=; b=Q3bapQSuA6t9+GAaROTQ4kLvVj4GFSP1H6EN6Nmf/HlKFPkTspWi/pDRfdXjTTjp5f Un+c4I+xl7DM5d+iQITBzrPTbrr0hIRzsKKVmhIc3C0465OcXFFWc0zMCXDEca8L9Msw /iTYzNJgDAxgPNwRVH7bSTqyJvvWwB4WXZ1Q51ECXJP5Ojw8gLPL71Ag+eQkH3Hipl0e 9MRaobUqe2aQXVwM2YZRbWJNR5tjCOv6ltC40TdWQVf+zDUJRrc6pEfhE8GibgyP3Amu vUZNFpq5zHRhKp2MafPXc88/c0Sd7Jrg2271IbkXDYLJsZIviJM0h6MqfQJqKQI9wXRt BTUQ==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774449049; x=1775053849; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8Y1/8Y58nPSbFPF/MiBgD2IOB6UCozTdaA9cRqPPTD8=; b=KRVtLnU2IloQGmnADJZujTcUQne1guwFbM3NnlFUFbTCryMRPMZRk4FRNNVsOdnc6I rupfk4lciWt9cieIYp3sdUDLDSvPP7OWp2vrXDtbnNAQxHZk2Z/TXS5gHmSfiBck2iN1 nvF+M1BAbIISkK4uLntu89PyI4+PGaPZkJt9TcuQshuCgMyV/poIsdC7JcIae/rvj8Ff 1oKutlr+K0esAC14sw7S9r7oWLspRAei07REjeIodjLmA18yqsQJAh5Xf8T2txqbW/Xj NEHAz+ZYY8sNJJYZAypRyyxBo5Psru362ZylCi9QDU615YnwWXAZe6DNxykK0SWExLk+ 1Mrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774449049; x=1775053849; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8Y1/8Y58nPSbFPF/MiBgD2IOB6UCozTdaA9cRqPPTD8=; b=cchWupAhHmIENHlOC4LoHTua7GD3IZk8m62tVp3L4j1ceH1CPzWjEEdxaBLR2ZF9rz w+eNDgUYB8ANyg15S2xpcaCrQAJxsSfVWege2oYqH8EVeg3rBm1hTCqN7xbVIUD3lX6/ z5pBY870o9cZckMe95yA1B48QlYuAADu4/QHtp674cln4xU77cvH3ybMC//PvUnyyB+y CJZz9IB3okR/qz0L7kFpPchMDi0o0GgjzJcCKG5/TVSkpN81VhXsZkrzbG4ZeCAuGvyG V4tCilFNYzIm9x2aWXrah2zmjt9LweddrmJfSdBC+sEURljabtA8LgSoAUsIz58EBqcK V2Sw== X-Forwarded-Encrypted: i=1; AJvYcCXawoFE3IfstmtUXbH8CyuJqLGoXzSFOzucbGhmZ1DgjF8gewcfyBH18+fLIG4u4p3ZOlH8hXwtx7DL@lists.postgresql.org X-Gm-Message-State: AOJu0Yz5NFpoIiZwPB19hmud4krlOmV708FZZUo1MMsMyIhytVEtRR9S lugHkgVATOQ41rokJK7SxQWFkgYjXNMz4V+590h6h36pAR8U8yVEh4zmZOIUvUYLDy9uqcLJKKo mHg1EIQ3kquXXzQncK270QLnGBp3gv3U= X-Gm-Gg: ATEYQzyxve622PoB7BzAE9ICt5K/y2usZYzt7gjx0xqtVeCpRc0mKU6FOph1yopSMwO nKWniKFjzqQZVs28YcXUvPwruotUqxIdDvna31bHEq7wF9wT2mQDgUqgZsWiEA6GqIDUAORgDgI IXIfzbb6soYsSTaRtBuLWUUxjJDDodUEcqtZCzY/ahFuRdbrBhoeBI+bHC84zFwxKcaDCF4ez+x NqLmMym1gNXCyM9I2CQwZs+koz3/Zd60LoM7ddjXm9CHFijPdI24JD1u7QOpYR7j51W+dEeHMJe tAx6zTsTu58hCpD66hQ= X-Received: by 2002:a05:6830:398a:b0:7d7:bf70:af2 with SMTP id 46e09a7af769-7d9d65141d0mr1992473a34.1.1774449049052; Wed, 25 Mar 2026 07:30:49 -0700 (PDT) MIME-Version: 1.0 References: <19437-0a65fb52d0f13a0d@postgresql.org> <233968.1774445501@sss.pgh.pa.us> In-Reply-To: From: Dmitriy Kuzmin Date: Thu, 26 Mar 2026 00:30:38 +1000 X-Gm-Features: AaiRm51p6kpgmKKOnUzv_Ug5lbDAfuFz5JpEDjMmKo8qkGOgmu4q4WWcagH_1Bc Message-ID: Subject: Re: BUG #19437: temp_tablespaces doesn't work inside a cursor? To: "David G. Johnston" Cc: Tom Lane , "pgsql-bugs@lists.postgresql.org" Content-Type: multipart/alternative; boundary="0000000000003da9d3064dda1dd7" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003da9d3064dda1dd7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > 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=E2=80=99t 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 =D1=81=D1=80, 25 =D0=BC=D0=B0=D1=80. 2026=E2=80=AF=D0=B3. =D0=B2 23:52, Dav= id G. Johnston : > On Wednesday, March 25, 2026, Tom Lane wrote: > >> PG Bug reporting form 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 o= f >> 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=E2=80=99t changed during the sequence. > > I haven=E2=80=99t tried to validate the cursor claim yet but; this defini= tely > isn=E2=80=99t the easiest format to consume and I can=E2=80=99t do much o= n my own presently. > > David J. > > --0000000000003da9d3064dda1dd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What doe= s "\o /dev/null" have to do with this?=C2=A0 That's a psql-si= de 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. T= his 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 consistent= ly reproducible result when executing a script.
The same result (creatin= g temporary files in different tablespaces) can be achieved by executing th= e specified commands manually without use of pg_sleep.

There is something odd here.=C2=A0 Loo= k at the log entry at 12:04:08.016; it uses base/ while the surrounding one= s use pg_tblspace/ and the setting itself hasn=E2=80=99t changed during the= sequence.

Absolutely correct. Furthermore, each execution = of SELECT pg_reload_conf() will cause the next query to create temporary fi= les in base/ once, regardless of the temp_tablespaces value. Try running th= e above commands manually and reviewing the logs; you'll see what I mea= n

=D1=81=D1=80, 25 =D0=BC=D0=B0=D1=80. 2026=E2=80= =AF=D0=B3. =D0=B2 23:52, David G. Johnston <david.g.johnston@gmail.com>:
On Wednesday, March 25, 2026, Tom Lan= e <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_tab= lespaces
> parameter and suspect a bug. At least, I haven't found a descripti= on 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 a= wareness of the async nature of this.=C2=A0

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

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

The comment applies to all three lines in = the following block, not just the first line.

Ther= e is something odd here.=C2=A0 Look at the log entry at 12:04:08.016; it us= es base/ while the surrounding ones use pg_tblspace/ and the setting itself= hasn=E2=80=99t changed during the sequence.

I hav= en=E2=80=99t tried to validate the cursor claim yet but; this definitely is= n=E2=80=99t the easiest format to consume and I can=E2=80=99t do much on my= own presently.

David J.

--0000000000003da9d3064dda1dd7--