Re: BUG #15182: Canceling authentication due to timeout aka Denialof Service Attack

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: BUG #15182: Canceling authentication due to timeout aka Denialof Service Attack
Дата
Msg-id 20180724045010.GA4736@paquier.xyz
обсуждение исходный текст
Ответ на Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack  (Andres Freund <andres@anarazel.de>)
Ответы Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Mon, Jul 23, 2018 at 09:17:53PM -0700, Andres Freund wrote:
> I might be mis-parsing this due to typos. Are you actually suggesting
> vacuum on system tables should depend on that GUC? If so, why? That's
> seems like a terrible idea.  It's pretty normal to occasionally have
> to vacuum them?

Oh, yes, that would be bad.  My mind has slipped here.  I have seen
manual VACUUMs on system catalogs for applications using many temp
tables...  So we would want to have only VACUUM FULL being conditionally
happening?  The question comes then about what to do when a VACUUM FULL
is run without a list of relations because expand_vacuum_rel() is not
actually the only problem.  Would we want to ignore system tables as
well except if allow_system_table_mods is on?  When no relation list is
specified, get_all_vacuum_rels() builds the list of relations which
causes vacuum_rel() to complain on try_relation_open(), so patching
just expand_vacuum_rel() solves only half of the problem for manual
VACUUMs.
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Making "COPY partitioned_table FROM" faster
Следующее
От: Andres Freund
Дата:
Сообщение: Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack