Re: BUG #15182: Canceling authentication due to timeout aka Denialof Service Attack - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: BUG #15182: Canceling authentication due to timeout aka Denialof Service Attack
Date
Msg-id 20180724045010.GA4736@paquier.xyz
Whole thread Raw
In response to Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack  (Andres Freund <andres@anarazel.de>)
Responses Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack  (Andres Freund <andres@anarazel.de>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Making "COPY partitioned_table FROM" faster
Next
From: Andres Freund
Date:
Subject: Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack