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.92) (envelope-from ) id 1jDrch-0000t4-Rd for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Mar 2020 15:25:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jDrcg-00007e-IQ for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Mar 2020 15:25:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1jDrcg-00007O-5n for pgsql-hackers@lists.postgresql.org; Mon, 16 Mar 2020 15:25:46 +0000 Received: from courriel.mines-paristech.fr ([77.158.173.149] helo=antispam-1.ensmp.fr) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jDrcd-0001Gb-B1 for pgsql-hackers@postgresql.org; Mon, 16 Mar 2020 15:25:44 +0000 Received: from smtp-5.mines-paristech.fr (smtp.mines-paristech.fr [77.158.173.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by antispam-1.ensmp.fr (antispam.mines-paristech.fr) with ESMTPS id 9BC9D561E0; Mon, 16 Mar 2020 16:20:21 +0100 (CET) Received: from pseudo (sfr-16.cri.mines-paristech.fr [77.158.180.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp-5.mines-paristech.fr (Postfix) with ESMTPSA id 7B66F20078; Mon, 16 Mar 2020 16:20:21 +0100 (CET) Date: Mon, 16 Mar 2020 16:20:21 +0100 (CET) From: Fabien COELHO X-X-Sender: fabien@pseudo To: Justin Pryzby cc: Alvaro Herrera , David Steele , pgsql-hackers@postgresql.org, "Bossart, Nathan" , Thomas Munro , Tom Lane Subject: Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*) In-Reply-To: <20200315212729.GC26184@telsasoft.com> Message-ID: References: <20200303200117.GI684@telsasoft.com> <20200303202313.GA28076@alvherre.pgsql> <20200305161838.GJ684@telsasoft.com> <20200306233507.GN684@telsasoft.com> <20200307214010.GB1357@telsasoft.com> <20200310183037.GA29065@telsasoft.com> <20200313131232.GO29065@telsasoft.com> <20200315212729.GC26184@telsasoft.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-CLAMAV-SCAN: ok X-VRSPAM-SCORE: -100 X-VRSPAM-STATE: legit X-VRSPAM-CAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudeffedgjeegucetufdoteggodetrfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvufgjkfhffgggtgesthdtredttdervdenucfhrhhomhephfgrsghivghnucevqffgnffjqfcuoegtohgvlhhhohestghrihdrvghnshhmphdrfhhrqeenucfkphepjeejrdduheekrddukedtrddvgedtnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk About v11, ISTM that the recursive function should check for symbolic links and possibly avoid them: sh> cd data/base sh> ln -s .. foo psql> SELECT * FROM pg_ls_dir_recurse('.'); ERROR: could not stat file "./base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo/base/foo": Too many levels of symbolic links CONTEXT: SQL function "pg_ls_dir_recurse" statement 1 This probably means using lstat instead of (in supplement to?) stat, and probably tell if something is a link, and if so not recurse in them. -- Fabien.