> 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
