Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hDOsG-0006nb-Rl for pgsql-bugs@arkaria.postgresql.org; Mon, 08 Apr 2019 07:39: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 1hDOsE-0006Qz-B7 for pgsql-bugs@arkaria.postgresql.org; Mon, 08 Apr 2019 07:39:22 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hDOsC-0006QI-KD for pgsql-bugs@lists.postgresql.org; Mon, 08 Apr 2019 07:39:22 +0000 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hDOs4-0000wC-DL for pgsql-bugs@lists.postgresql.org; Mon, 08 Apr 2019 07:39:20 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id BB9BE2D6; Mon, 8 Apr 2019 03:39:09 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 08 Apr 2019 03:39:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= date:from:to:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=vJYyM0hY/wBGh9DRrB3i0P16bK+ y6HbGqSju0FHW3V0=; b=j22PzI6Mh5/Q2RArXaKvI7jaHwVKKlmZIhVNunnf5bx E6tWE4xHN+oc2Bom8tJwaTKx6JGT3Z+IlDTaperj3qTLmFGNakpmmbOMa0+P7HZE jmv3upv08PD8Ow9snxcy2Ip2viDYyoA5kNKR7A9n98G1IjgkBNAj2S/M5qh007iu CO+tn0ANesbxumdkV7qHOYQpEleQ7gouXw9086oNQ9T5HjjbECPfa5MrgbwanOPU g0nvrlFF/O+Nrpg+vf+kiAO700TiSPBFbhk6HvGnzwR+du4QAv5yhWhyA6cj72Tu xmfFXAC2zl9Z+sQP7308mN0Nhz25KHaaEQFzCtU6jww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=vJYyM0 hY/wBGh9DRrB3i0P16bK+y6HbGqSju0FHW3V0=; b=HHv90mGy50t0oEMfkI0PTe XhmGz1JchJMErUCEJ1s9kiM0up3bVq5f7GAX9B6tyv543hz7zxiRtgujLKPpHRU4 zX0lsEw2m8m5EcXhW/YlrGV5/t6q5JkSYNZ+g/Cno7i86J6sAqzf6u+iZQHOLsPn A3OZ4S5wcJbqoNovj4dkjjY/iJV16DmR7RLojxtOYTCCLLRlaZHxsuxx55ufgREI mPT0yA4OqteBdqESqoi3N11hgZL+pV3axbjjfwPf1rOfzXuaEEb7HPPfHTzincDG 2hcVGZgEMpaDBrZ2pZkpHE9e2uj2lLElG3RH0AoAtrepY73iPgVVVZ8Q59ocOR3g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddvgdduvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucgfrhhlucfvnfffucdljedtmdenucfjughrpeffhf fvuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofhitghhrggvlhcurfgrqhhu ihgvrhcuoehmihgthhgrvghlsehprghquhhivghrrdighiiiqeenucfkphepudduuddrud dtvddrudektddrudekheenucfrrghrrghmpehmrghilhhfrhhomhepmhhitghhrggvlhes phgrqhhuihgvrhdrgiihiienucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from paquier.xyz (ee0822lan1.rev.em-net.ne.jp [111.102.180.185]) by mail.messagingengine.com (Postfix) with ESMTPA id A5593E42C9; Mon, 8 Apr 2019 03:39:07 -0400 (EDT) Date: Mon, 8 Apr 2019 16:39:03 +0900 From: Michael Paquier To: cyberdemn@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #15734: Walsender process crashing when executing SHOW ALL; Message-ID: <20190408073903.GJ2712@paquier.xyz> References: <15734-2daa8761eeed8e20@postgresql.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fUvfsPTz/SzOZDdw" Content-Disposition: inline In-Reply-To: <15734-2daa8761eeed8e20@postgresql.org> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --fUvfsPTz/SzOZDdw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Apr 04, 2019 at 07:54:19AM +0000, PG Bug reporting form wrote: > I don't think that such a crash is expected behavior. Either it should > return the table with all settings or report simply error out with message > 'unrecognized configuration parameter "ALL"'. No, it's not correct to just disallow ALL as we have a similar check in GetConfigOptionByName() for individual parameters. Problem is origically from 25fff40, and got worse as of 0c8910a0. A superuser is able to get the list of parameters, but I can easily see the failure when using a plain replication user. A replication user is one which can take a full base backup, so he can easily retrieve the full list of parameters anyway. What about bypassing the problem and just allow WAL sender contexts to always have access to parameter values? I don't think that this is much a security issue if one thinks about the access to BASE_BACKUP. -- Michael --fUvfsPTz/SzOZDdw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlyq+pcACgkQnvQgOdby QH1meg/+IAk6C3fu7TYRsNiLzCZ7WVRH4VlZpwW0C2HFEcm5zC0PsFtNqeFDhG2e RAZcNnBQEa8mshf3dPIbeLeSO6dS/eBrHdM4S8otU3op27EC5gfLeeRtlLy5WUkK c4fJMRfVlTAFATrQm77XJGBgpoc0eIlND3smKqyDOwBcwgRvft5cTnz1yqc/fLDY vw7v+Nso5hcZDDQmlmnspuvtjLqzlHMpuGrY18rhFSZsdDVJTzs6TU3N8ACkc+M0 0EnnLAz9u1u6ST4eiA2ncj5CHGVp92of2GgX58UNfcufi/XOlFSSvlyvHTHOfJcL fHbJlyCO81erHnepRENrnR7t1N0GbpLO9qpeJl7ggJiU30+R2RFqUWq/lOtbGVTF QT6QcftujoYcOFiGgQEkkMxLlvYg3ejJmXw/Rbyy8sPEwe6jPmIKlYjydyuC5Afz mQzZXfbKgb81+8leoKedB/udfQGfWVXUN+OQ2WRYFN6fV4u7u30xhcy2k/HuQkAV TYNSdGuf8mDuz5EXw1DjqCZRl/cuSH2XBaJzxxsV7UH3Ez00M8Xi9Mdik9L+/FlT Kghp0ub49dwYlAAb5o/ga/6Ww3L/CrY1c6g2AEcuYCkG8BP1Gd+PoyXrtJB9f15F LY/yjbPO9TGudMp3rp6F4tBg2i3qshFZNj9AmsiAvZPdDHE3gLY= =dzOW -----END PGP SIGNATURE----- --fUvfsPTz/SzOZDdw--