Re: BUG #19437: temp_tablespaces doesn't work inside a cursor?

Dmitriy Kuzmin <kuzmin(dot)db4(at)gmail(dot)com> writes:
> Any news on these issues?

I don't see any bug here. You're expecting the ALTER SYSTEM SET
change to propagate instantaneously after pg_reload_conf(), but
it doesn't. I cannot replicate your claim that the setting
changes once it has been received, either.

The fact that DECLARE CURSOR isn't using a temp tablespace is
intentional, according to the comments in OpenTemporaryFile:

* If some temp tablespace(s) have been given to us, try to use the next
* one. If a given tablespace can't be found, we silently fall back to
* the database's default tablespace.
*
* BUT: if the temp file is slated to outlive the current transaction,
* force it into the database's default tablespace, so that it will not
* pose a threat to possible tablespace drop attempts.

The reason it thinks the temp file may need to outlive the current
transaction is that we're putting the FETCH results into the current
Portal's holdStore, which is specifically intended to possibly outlive
the transaction. Since you didn't say WITH HOLD in the DECLARE
CURSOR, maybe there's an optimization possibility there. But I'm
not sure --- I think the details of the wire protocol may foreclose
throwing the Portal's results away until it's explicitly closed.

I didn't go looking to see how well these details are documented.

regards, tom lane