Thanks for the answer. Here is a link that helped me in that case: https://community.synopsys.com/s/article/Postgresql-log-LOG-autovacuum-found-orphan-temp-table-pg-temp-xxx-loblist-in-database-cim
Detailed answer copied from this Source at community.synopsys.com:
Possible Reasons from PostgreSQL Community
- The applications were using temporary tables. The rows for temporary tables were created in pg_namespace (one row for pg_temp_n) and pg_class. Those rows were replicated to the standby. The data files for the temporary tables were not replicated.
- The server crashed the standby was promoted to the primary.
- The new primary performed recovery, but the rows for temporary tables in the system catalog were left.
- The applications resumed processing. However, the workload got lighter, so the zombie pg_temp_n entries were not recycled.
- autovacuum workers found the zombie temporary table entries in the system catalog, repeatedly emitting lots of messages.
And the very helpful SQL-Query that they provided at community.synopsys.com:
Query to find those schemas :
select relname,nspname from pg_class
join pg_namespace on (relnamespace=pg_namespace.oid)
On finding you can drop those schemas, if you want to get rid of the messages, just do:
DROP SCHEMA pg_temp_NNN CASCADE;