From: Tom Lane <tgl@sss.pgh.pa.us>
To: Justin Pryzby <pryzby@telsasoft.com>
cc: pgsql-hackers@postgresql.org, Fabien COELHO <coelho@cri.ensmp.fr>,
        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
In-reply-to: <20200329171415.GL20103@telsasoft.com>
References: <20200311111921.GQ29065@telsasoft.com>
 <21724.1583955158@sss.pgh.pa.us> <20200312121156.GB29065@telsasoft.com>
 <20200316155306.GM26184@telsasoft.com> <3061.1584409130@sss.pgh.pa.us>
 <20200317020017.GT26184@telsasoft.com> <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>
Comments: In-reply-to Justin Pryzby <pryzby@telsasoft.com>
	message dated "Sun, 29 Mar 2020 12:14:15 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <29511.1585502524.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Sun, 29 Mar 2020 13:22:04 -0400
Message-ID: <29512.1585502524@sss.pgh.pa.us>
Precedence: bulk

Justin Pryzby <pryzby@telsasoft.com> writes:
> On Sun, Mar 29, 2020 at 12:37:05PM -0400, Tom Lane wrote:
>> After looking at the callers of pg_ls_dir_files, and noticing that
>> it's already defined to ignore anything that's not a regular file,
>> I think switching to lstat makes sense.

> Yea, only pg_ls_dir() shows special file types (and currently the others=
 even
> hide dirs).

> The essence of your patch is to ignore ENOENT, but you also changed to u=
se
> lstat(), which seems unrelated.  That means we'll now hide (non-broken)
> symlinks.  Is that intentional/needed ?

Well, the following comment says "ignore anything but regular files",
so I'm supposing that that is the behavior that we actually want here
and failed to implement correctly.  There might be scope for
additional directory-reading functions, but I'd think you'd want
more information (such as the file type) returned from anything
that doesn't act this way.

In practice, since these directories shouldn't contain symlinks,
it's likely moot.  The only place in PG data directories where
we actually expect symlinks is pg_tablespace ... and that contains
symlinks to directories, so that this function would ignore them
anyway.

			regards, tom lane