Re: dropdb --force - Mailing list pgsql-hackers

From Marti Raudsepp
Subject Re: dropdb --force
Date
Msg-id CABRT9RD=QQExSQztrz5-ZSCxG96RjffL8_1v+K2ouqe=ahao+A@mail.gmail.com
Whole thread Raw
In response to Re: dropdb --force  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: dropdb --force  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: dropdb --force  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: dropdb --force  (Filip Rembiałkowski <filip.rembialkowski@gmail.com>)
List pgsql-hackers
Hi

> út 18. 12. 2018 v 16:11 odesílatel Filip Rembiałkowski <filip.rembialkowski@gmail.com> napsal:
>> Please share opinions if this makes sense at all, and has any chance
>> going upstream.

Clearly since Pavel has another implementation of the same concept,
there is some interest in this feature. :)

On Tue, Dec 18, 2018 at 5:20 PM Pavel Stehule <pavel.stehule@gmail.com> wrote:
> Still one my customer use a patch that implement FORCE on SQL level. It is necessary under higher load when is not
easyto synchronize clients. 

I think Filip's approach of setting pg_database.datallowconn='false'
is pretty clever to avoid the synchronization problem. But it's also a
good idea to expose this functionality via DROP DATABASE in SQL, like
Pavel's patch, not just the 'dropdb' binary.

If this is to be accepted into PostgreSQL core, I think the two
approaches should be combined on the server side.

Regards,
Marti Raudsepp


pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)
Next
From: Tom Lane
Date:
Subject: Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)