Обсуждение: proposal: DROP DATABASE variant that kills active sessions
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. thanks
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
thanks
--
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 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
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
>> Timbira: http://www.timbira.com.br
>> Blog: http://fabriziomello.github.io
>> Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello
>> Github: http://github.com/fabriziomello
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
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Вложения
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