Re: dropdb --force

Поиск
Список
Период
Сортировка
От Marti Raudsepp
Тема Re: dropdb --force
Дата
Msg-id CABRT9RD=QQExSQztrz5-ZSCxG96RjffL8_1v+K2ouqe=ahao+A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: dropdb --force  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: John Naylor
Дата:
Сообщение: Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)