Thank you for your response.
We encountered a scenario where orphaned temporary views are preventing DDL
operations on a table, such as "ALTER TABLE xxx ALTER COLUMN xxx TYPE xxx." The
corresponding error message is "ERROR: cannot alter type of a column used by a view or rule."
In this case, the only way to resolve this is to manually delete the temporary
views. However, ordinary users do not have the permission to do so, resulting in
the error "ERROR: permission denied for schema pg_temp_xxx." Does this mean that
a superuser is the only one who can delete them? This is somewhat inconvenient.
The reuse of the temp namespace requires the same "ProcNumber"; however,
max_connections may be quite large, and the application may not frequently
create new connections. Even if the same "ProcNumber" is encountered, it does
not guarantee that the temp namespace will be used. Therefore, overall, the
reuse triggering cleanup might be very timely.
Additionally, I tested a scenario where temporary view B depends on temporary
view A. By observing the debug logs, I found that the current implementation can
handle such dependency scenarios without errors. If temporary view B depends on
temporary view A, then deleting temporary view A in the first round of the loop
will also delete B. In the second round of the loop, it will exit early due to
the check if (!HeapTupleIsValid(tuple)). Both RemoveTempRelations() and
do_autovacuum() call performDeletion() with the DROP_CASCADE option, and the
other parameters are generally consistent, so the automatic cleanup also seems
to be safe, right? There may be aspects I haven't considered…
Best regards,
Yupeng Zhao 
