On Sat, Nov 15, 2025 at 10:00 AM Peter 'PMc' Much < [email protected]> wrote:
> > Hi, > trying to unload (and then reload) a development application, > failed with this error: > > fin(dev)> Que.migrate! version: 0 > ERROR: cannot drop table que_jobs because other objects depend on it > (PG::DependentObjectsStillExist) > DETAIL: function pg_temp_7.lock_and_update_priorities(jsonb,que_jobs) > depends on type que_jobs > HINT: Use DROP ... CASCADE to drop the dependent objects too. > > > The routine was trying to remove all database objects in the order > they were formerly created, In the *REVERSE* order they were created? [snip] > I would rather figure out what actually went wrong (and then probably > fix it for the future). > > So I started to investigate. Enabling "System Objects" in pgadmin4, > I find a vast amount of pg_temp_### schemas, and therein I actually > find the offending object - it indeed contains some stuff the Que > software would probably use. > > Then, trying to figure out how this is supposed to be cleaned up, > I find this article by subject matter expert Laurenz Albe: > https://stackoverflow.com/a/79693897 > > 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. -- Death to <Redacted>, and butter sauce. Don't boil me, I'm still alive. <Redacted> lobster!
