Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fhpHE-0002AQ-VW for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Jul 2018 04:50:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fhpHC-0007Vy-4i for pgsql-hackers@arkaria.postgresql.org; Tue, 24 Jul 2018 04:50:22 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fhpHB-0007Vh-Mj for pgsql-hackers@lists.postgresql.org; Tue, 24 Jul 2018 04:50:21 +0000 Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fhpH8-0000vZ-EX for pgsql-hackers@lists.postgresql.org; Tue, 24 Jul 2018 04:50:20 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 89A4A797; Tue, 24 Jul 2018 00:50:16 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 24 Jul 2018 00:50:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=jjBt8q6Y+t3/eiCfeu4HqLZj8dOI94p9tAgRqBLM96c=; b=syvcq2jo kgttLK2L1ou70fAxZYoHCzu5go8A981IGuWjgOd/F2281a5oA/4Q7M0PDkPoKpd6 LprPUXR0UYOEJPevjDJ4X0sBXfpLVSxrEAOLCtikRzfHedZyS5KuS6II2gUy4laC 1F/SS669h8v2CH15H6eI26FNPDm31gR+0e+Dy4LHboA13NM2m2vSp/WevyIQxgHq Nhb/Bis8m8YsFknYaCZhlf/pKwdBQAwyia+VEDIf2Yj0rs5GeWLBAP0hnsD6wPBZ dlXJ6/X/k5D4BmhumftL5NvUbUNC7YcxXI4fU+pwcdtdgkiLvz44eOavnWBeRpfM BrRsc62hPmDNcw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=jjBt8q6Y+t3/eiCfeu4HqLZj8dOI9 4p9tAgRqBLM96c=; b=igg6GLt25qUjj/aiD0VYi7hHIyjf5+2BioWYGvgwNFTPB X81ajhGW9xGl8t9/z2PcJH5oXQJQYd7XE7xnSDqXUqZbvHl/yauDp1ulondaVeX9 dUivBS3Usdq/U6bvAQIDY8Hr1icEowL/m10x3sgILRFI5Kw0/BVwIV6vQlnMkmAs t+UZZrIrKnzx5t0DHIJWGGKPhlbmuz+wqmnb+hzIbZYuEK9RpAP5r2wxW7o2qqVJ q9fLoahTx9beLYaT0uMO4kgMRMYeOUy99bQiLv7ea6sWSn+gv05NRo0FwJ3YKlHx KvbXbgFI/al0xjnIGucHwHov9BdTY621+nieG3fFA== X-ME-Proxy: X-ME-Sender: Received: from paquier.xyz (mp76f1fb98.ap.nuro.jp [118.241.251.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 74D19E4513; Tue, 24 Jul 2018 00:50:13 -0400 (EDT) Date: Tue, 24 Jul 2018 13:50:10 +0900 From: Michael Paquier To: Andres Freund Cc: pgsql-hackers@lists.postgresql.org, Robert Haas , Jeremy Schneider , PostgreSQL-development , "Albin, Lloyd P" Subject: Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack Message-ID: <20180724045010.GA4736@paquier.xyz> References: <152512087100.19803.12733865831237526317@wrigleys.postgresql.org> <9145334b-9583-124c-012e-7d58039ad417@amazon.com> <20180724041403.GF4035@paquier.xyz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAltWsAIACgkQnvQgOdby QH13nw/+KPIBZ69he14m2G+vG3EwySfav0ma1ltXSvOYHsuoMWVLr7z00pPhCP8o adOi88k6JPFtOLttKQtwznEaeuLkBbKTLNL3KAWlFxkNIrnj2PyQ5vqEO89mXXqt B0MmbnUfnwGlDeabFRq+JToIhUhhW/9MY7gjrvJ9UYniIbJAkYe93swV36yU3NEv gzQ8C3TKgzVqk61+UISa1q+Qbn/lLfZHNH6Kk0l6IFCURcvCyi+Mxv9qyqlspvOO 7NsLcwSBj41zgNx30/B9MaRnDPtg7FNQ8UdLFvIlyXXyWh2eWmmPaHAEp/zwT7Y8 imTgvYlw2LUfs1zYU2+E7cFf8hm+uovQQ5SSgvJ+8nPXZi6aG3WyF2mQU3KW4WQf ZHYOyYYWZh5ux2Ne1BMnXw9I/g4/lqAMgyK+3F778T6dQENkNeeNVFI8KHXFlC6q bLJqMjR1Dra4emzttVsaV3WP/e2co5xd55yaOwyWbS+CgjqwThgnqBYHK19r2Bqa NiDL9cbgWscR8NlgKOS1U6JFgaMTJJ2z8HfPMTSoINY3JDrbhNS4HxwUGkTr0E6Z syanOGpY6H4i/LsQ1jqNM/If0WK0/P2qfG4mQGUZojeJC85/7D5+qeTJ+qxKqXut 0X9IUmJ8/8cf0XCMsT0KXIkknEEb0SSzZNsFGE++PAFa5bd9DHs= =Lw0x -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ--