In an interesting epilogue to this thread, I just encountered
something unusual.
Since having disabled autovacuum in the cluster in which it was
preventing dropdb from working (because autovacuum the autovacuum
daemon was behaving as a user accessing the database), dropdb has
been
On Mar 11, 2006, at 4:13 PM, Tom Lane wrote:
For a real solution, perhaps DROP DATABASE could somehow look to
determine if there's an autovac daemon active in the target database,
and if so send it a SIGINT and wait for it to go away.
In general, it also seems like a --force option or
Thomas F. O'Connell [EMAIL PROTECTED] writes:
On Mar 11, 2006, at 4:13 PM, Tom Lane wrote:
For a real solution, perhaps DROP DATABASE could somehow look to
determine if there's an autovac daemon active in the target database,
and if so send it a SIGINT and wait for it to go away.
In general,
Tom Lane wrote:
Thomas F. O'Connell [EMAIL PROTECTED] writes:
On Mar 11, 2006, at 4:13 PM, Tom Lane wrote:
For a real solution, perhaps DROP DATABASE could somehow look to
determine if there's an autovac daemon active in the target database,
and if so send it a SIGINT and wait for it to go
I administer a network where a postgres database on one machine is
nightly dumped to another machine where it is restored (for
verification purposes) once the dump completes. The process is roughly:
pg_dump remotedb
dropdb localdb
pg_restore remotedb.pgd
We recently upgraded the system to
Thomas F. O'Connell wrote:
I administer a network where a postgres database on one machine is
nightly dumped to another machine where it is restored (for verification
purposes) once the dump completes. The process is roughly:
pg_dump remotedb
dropdb localdb
pg_restore remotedb.pgd
We
On Mar 11, 2006, at 2:44 PM, Matthew T. O'Connor wrote:
Thomas F. O'Connell wrote:
I administer a network where a postgres database on one machine is
nightly dumped to another machine where it is restored (for
verification purposes) once the dump completes. The process is
roughly:
Matthew T. O'Connor matthew@zeut.net writes:
I suppose you could instead:
connect to local postmaster
disable autovacuum
pg_dump remotedb
dropdb localdb
pg_restore remotedb.pgd
enable autovacuum
For a real solution, perhaps DROP DATABASE could somehow look to
determine if there's an
