On 22/06/2012 12:07 AM, Tom Lane wrote:
SELECT pg_terminate_backend(procpid)
FROM pg_stat_activity
WHERE datname = 'dropme';
ERROR: must be superuser to signal other server processes
As far as that goes, there's a pending patch to reduce the privileges
required to use pg_terminate_backend. I'm
Evan Martin writes:
> That's a fair point, so perhaps DROP DATABASE should still fail if the
> /current/ connection is to that database (preferably with a helpful
> error like "you cannot drop the database you are connected to").
It does that.
> SELECT pg_terminate_backend(procpid)
> FROM pg_s
Evan Martin wrote:
> Like I said in my original post, I understand the workaround. I just
> think that:
>
> 1) The workaround requires extra work for each developer (or at least
> each client application) using PostgreSQL, while a fix in PostgreSQL
> would solve this once and for all.
For a devel
>
>
> SELECT pg_terminate_backend(procpid)
> FROM pg_stat_activity
> WHERE datname = 'dropme';
>
> ERROR: must be superuser to signal other server processes
>
> You can try this approach.
http://archives.postgresql.org/pgsql-general/2012-04/msg00100.php
---
Regards,
Raghavendra
EnterpriseDB Corp
On 21/06/2012 10:20 PM, Sergey Konoplev wrote:
On Thu, Jun 21, 2012 at 2:03 PM, Evan Martin
wrote:
1) The workaround requires extra work for each developer (or at least each
client application) using PostgreSQL, while a fix in PostgreSQL would solve
this once and for all.
It is not clean what
On Thu, Jun 21, 2012 at 2:03 PM, Evan Martin
wrote:
> 1) The workaround requires extra work for each developer (or at least each
> client application) using PostgreSQL, while a fix in PostgreSQL would solve
> this once and for all.
It is not clean what database you need to reconnect automatically
Like I said in my original post, I understand the workaround. I just
think that:
1) The workaround requires extra work for each developer (or at least
each client application) using PostgreSQL, while a fix in PostgreSQL
would solve this once and for all.
2) The workaround requires superuser pr
On Tue, Jun 19, 2012 at 1:40 PM, Evan Martin
wrote:
> When I'm developing against a PostgreSQL database I often drop and re-create
> it and I often find that the drop fails, because it's "in use by other
> users". This is really annoying, especially when I know full well there are
> no other users
Hi All,
When I'm developing against a PostgreSQL database I often drop and
re-create it and I often find that the drop fails, because it's "in use
by other users". This is really annoying, especially when I know full
well there are no other users - it's just me.
I'm aware of the workaround:
