On Sat, Nov 15, 2025 at 10:28:18AM -0500, Ron Johnson wrote: ! On Sat, Nov 15, 2025 at 10:00 AM Peter 'PMc' Much <
! > The routine was trying to remove all database objects in the order ! > they were formerly created, ! ! ! In the *REVERSE* order they were created? I might suppose so ;) ! > Temporary tables are automatically removed when the database ! > session terminates. Consequently, your users are running long ! > database sessions. ! > ! > Sadly, this does not make much sense to me, because there are ! > (currently) no sessions on the database (checked with 'ps ax'). ! > ! ! Abnormal session termination is the typical reason for them to hang around. Hmja. I did a bit of research in the meantime. What the Que software does, is this: https://github.com/que-rb/que/blob/17fb2c3b75b37599bf17043dbb692555f582f249/lib/que/poller.rb#L188 Now if I do the same: postgres=# CREATE FUNCTION pg_temp.mycrap() RETURNS text AS $$ select '1'; $$ LANGUAGE SQL; and then quit the psql, the pg_tmp_10 schema stays, but the function is gone. Okay. If I instead kill-9 the psql, then - the function is gone. Very well. Then, if the serving process is hard killed... then some more things might fall down - no, I don't want to try that currently, and it shouldn't happen anyway. But what about power loss? We have here, once or twice a year - not enough to warrant an UPS, but to consider. Lets find out if these objects are persisted... they are. That could be the explanation. At least during a clean restart (as I just did) the server does not consider that there cannot be any sessions right now, and remove these objects. Then most likely, during an unclean restart it doesn't either. (maybe that cannot be done so easily with replicas or such - no idea) Okay, that figures as a root case. And anyway it seems there is no problem in just dropping these things while the application is down. cheers, PMc
