Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack
От | Andres Freund |
---|---|
Тема | Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack |
Дата | |
Msg-id | B8A865D7-DDD0-4E04-9077-02C76B206FF5@anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #15182: Canceling authentication due to timeout aka Denialof Service Attack (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: BUG #15182: Canceling authentication due to timeout aka Denialof Service Attack
Re: BUG #15182: Canceling authentication due to timeout aka Denialof Service Attack |
Список | pgsql-hackers |
On July 23, 2018 9:50:10 PM PDT, Michael Paquier <michael@paquier.xyz> wrote: >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. I think any such restriction is entirely unacceptable. FULL or not. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
В списке pgsql-hackers по дате отправления: