| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Jeremy Schneider <schnjere(at)amazon(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, "Albin, Lloyd P" <lalbin(at)scharp(dot)org> |
| Subject: | Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack |
| Date: | 2018-07-24 04:50:10 |
| Message-ID: | 20180724045010.GA4736@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-07-24 04:51:54 | Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack |
| Previous Message | Andres Freund | 2018-07-24 04:17:53 | Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2018-07-24 04:51:54 | Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack |
| Previous Message | David Rowley | 2018-07-24 04:27:59 | Re: Making "COPY partitioned_table FROM" faster |