From: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Steele <david(at)pgmasters(dot)net>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Subject: | Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction |
Date: | 2020-03-31 08:06:43 |
Message-ID: | 20200331080643.GE14618@telsasoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Artur Zakirov | 2020-03-31 08:34:18 | Re: truncating timestamps on arbitrary intervals |
Previous Message | John Naylor | 2020-03-31 08:05:55 | Re: tweaking perfect hash multipliers |