Date: Tue, 31 Mar 2020 03:06:43 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org,
	Alvaro Herrera <alvherre@2ndquadrant.com>,
	David Steele <david@pgmasters.net>,
	"Bossart,    Nathan" <bossartn@amazon.com>,
	Thomas Munro <thomas.munro@gmail.com>
Subject: Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at
 end-of-transaction
Message-ID: <20200331080643.GE14618@telsasoft.com>
References: <24244.1585415634@sss.pgh.pa.us>
 <20200328183904.GI20103@telsasoft.com>
 <28906.1585422475@sss.pgh.pa.us>
 <27064.1585499825@sss.pgh.pa.us>
 <20200329171415.GL20103@telsasoft.com>
 <29512.1585502524@sss.pgh.pa.us>
 <20200329201215.GM20103@telsasoft.com>
 <alpine.DEB.2.21.2003300704430.16227@pseudo>
 <4028.1585579463@sss.pgh.pa.us>
 <alpine.DEB.2.21.2003310723560.16227@pseudo>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <alpine.DEB.2.21.2003310723560.16227@pseudo>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On Tue, Mar 31, 2020 at 07:36:03AM +0200, Fabien COELHO wrote:
> > > As I wrote about an earlier version of the patch, ISTM that instead of
> > > reinventing, extending, adapting various ls variants (with/without
> > > metadata, which show only files, which shows target of links, which shows
> > > directory, etc.) we would just need *one* postgres "ls" implementation
> > > which would be like "ls -la arg" (returns file type, dates), and then
> > > everything else is a wrapper around that with appropriate filtering that
> > > can be done at the SQL level, like you started with recurse.
> > 
> > Yeah, I agree that some new function that can represent symlinks
> > explicitly in its output is the place to deal with this, for
> > people who want to deal with it.
> > 
> > In the meantime, there's still the question of what pg_ls_dir_files
> > should do exactly.  Are we content to have it ignore symlinks?
> > I remain inclined to think that's the right thing given its current
> > brief.
> 
> My 0.02€:
> 
> I agree that it is enough to reproduce the current behavior of various
> existing pg_ls* functions, but on the other hand outputing a column type
> char like ls (-, d, l…) looks like really no big deal. I'd say that the only
> reason not to do it may be to pass this before feature freeze.

Remember, there's two threads here, and this one is about the bug in stable
releases ($SUBJECT), and now the instability in the test that was added with
its fix.

I suggest to leave stat() alone in your patch for stable releases.  I think
it's okay if we change behavior so that a broken symlink is skipped instead of
erroring (as a side effect of skipping ENOENT with stat()).  But not okay if we
change pg_ls_logdir() to hide symlinks in back braches.

-- 
Justin