proposal: DROP DATABASE variant that kills active sessions

Hi

2015-10-16 12:13 GMT+02:00 Filip Rembiałkowski <
filip.rembialkowski@gmail.com>:

DROP DATABASE mydb CONCURRENTLY;

That would perform forced shutdown

1) reject any new backends to mydb
2) terminate old backends
3) drop db

40 upvotes here http://dba.stackexchange.com/a/11895/3710 inspired me
to propose this improvement.

If you think it's a good idea please include it as a low-priority TODO
item.

in GoodData we have this feature implemented - little bit different named -
DROP DATABASE FORCE

It is useful in complex environment with mix of pooled and not pooled
connections - and in our environment - about 2K databases per server with
lot of dropped / created databases per server / per day.

I can publish this patch, if there will be any interest.

last note: little bit related topic - we have some patches for CREATE
DATABASE - longer waiting for locking template1 - although there are some
opened issues - like any CREATE DATABASE requires checkpoint, and it is
slower in our environment.

Regards

Pavel

On Fri, Oct 16, 2015 at 6:22 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:

in GoodData we have this feature implemented - little bit different named -
DROP DATABASE FORCE

It is useful in complex environment with mix of pooled and not pooled
connections - and in our environment - about 2K databases per server with
lot of dropped / created databases per server / per day.

I can publish this patch, if there will be any interest.

I think this would be a useful feature. What would one do about
prepared transactions?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Fri, Oct 16, 2015 at 4:12 PM, Robert Haas <robertmhaas@gmail.com> wrote:

On Fri, Oct 16, 2015 at 6:22 AM, Pavel Stehule <pavel.stehule@gmail.com>

wrote:

in GoodData we have this feature implemented - little bit different

named -

DROP DATABASE FORCE

It is useful in complex environment with mix of pooled and not pooled
connections - and in our environment - about 2K databases per server

with

lot of dropped / created databases per server / per day.

I can publish this patch, if there will be any interest.

I think this would be a useful feature. What would one do about
prepared transactions?

Isn't "rollback all prepared" before an option?

Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL

2015-10-16 21:12 GMT+02:00 Robert Haas <robertmhaas@gmail.com>:

On Fri, Oct 16, 2015 at 6:22 AM, Pavel Stehule <pavel.stehule@gmail.com>
wrote:

in GoodData we have this feature implemented - little bit different

named -

DROP DATABASE FORCE

It is useful in complex environment with mix of pooled and not pooled
connections - and in our environment - about 2K databases per server with
lot of dropped / created databases per server / per day.

I can publish this patch, if there will be any interest.

I think this would be a useful feature. What would one do about
prepared transactions?

It doesn't solve it - GoodData doesn't use it - so I didn't solve this
question - it emulates manual maintenance. In our solution can be some
opened issues.

Patch attached

Regards

Pavel

On 2015-10-16 16:32:25 -0300, Fabr�zio de Royes Mello wrote:

On Fri, Oct 16, 2015 at 4:12 PM, Robert Haas <robertmhaas@gmail.com> wrote:

I think this would be a useful feature. What would one do about
prepared transactions?

Isn't "rollback all prepared" before an option?

Not necessarily - what if shared objects are affected by the
transaction?

I think it's fine to just not support FORCE in that case - I don't think
it's all that common.

Greetings,

Andres Freund

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers