Обсуждение: 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
<div dir="ltr"><div class="gmail_extra"><br />On Fri, Oct 16, 2015 at 4:12 PM, Robert Haas <<a href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>>wrote:<br />><br />> On Fri, Oct 16, 2015 at 6:22AM, Pavel Stehule <<a href="mailto:pavel.stehule@gmail.com">pavel.stehule@gmail.com</a>> wrote:<br />> >in GoodData we have this feature implemented - little bit different named -<br />> > DROP DATABASE FORCE<br />>><br />> > It is useful in complex environment with mix of pooled and not pooled<br />> > connections- and in our environment - about 2K databases per server with<br />> > lot of dropped / created databasesper server / per day.<br />> ><br />> > I can publish this patch, if there will be any interest.<br/>><br />> I think this would be a useful feature. What would one do about<br />> prepared transactions?<br/>><br /><br /></div><div class="gmail_extra">Isn't "rollback all prepared" before an option?<br /></div><divclass="gmail_extra"><br /></div><div class="gmail_extra">Regards,<br /></div><div class="gmail_extra"><br />--<br/>Fabrízio de Royes Mello<br />Consultoria/Coaching PostgreSQL<br />>> Timbira: <a href="http://www.timbira.com.br">http://www.timbira.com.br</a><br/>>> Blog: <a href="http://fabriziomello.github.io">http://fabriziomello.github.io</a><br/>>> Linkedin: <a href="http://br.linkedin.com/in/fabriziomello">http://br.linkedin.com/in/fabriziomello</a><br/>>> Twitter: <a href="http://twitter.com/fabriziomello">http://twitter.com/fabriziomello</a><br/>>> Github: <a href="http://github.com/fabriziomello">http://github.com/fabriziomello</a></div></div>
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