> There are obvious race conditions in that assumption. Why don't you > just try the drop and see if it succeeds? > > regards, tom lane > I don't follow - why is there a race condition? I'm driving the commands into postgresql via the command line. The command that does the query on the pg_stat_activity table happens quite a while before my attempt to drop the table - and it's logging into the template1 database, rather than the database I want to drop. The drop attempt comes later, in a subsequent psql command line invocation. The drop command also logs in using the template1 database. Does the psql command line client connection not get cleaned up immediately, or something like that? No other command or tool will access this database (to my knowledge) in between the two commands. So what is the mystery user that I'm finding using the table? My only guess so far is that it was the autovac daemon - but I don't know enough about how that works to know if that is even a reasonable guess. Due to the nature of the installer tool I'm driving this fun, parsing back the output of the psql commands isn't much fun... and there are cases where a failure is acceptable (the database already doesn't exist, etc). If I can have a reliable drop command that always works, it would be much easier. Thanks, Dan -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
