pg_ls_tmpdir to show shared filesets - Mailing list pgsql-hackers

From Justin Pryzby
Subject pg_ls_tmpdir to show shared filesets
Date
Msg-id 20191213053931.GV2082@telsasoft.com
Whole thread Raw
Responses Re: pg_ls_tmpdir to show shared filesets  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On Thu, Dec 12, 2019, Justin Pryzby wrote in 20191212180506.GR2082@telsasoft.com:
> Actually, I tried using pg_ls_tmpdir(), but it unconditionally masks
> non-regular files and thus shared filesets.  Maybe that's worth discussion on a
> new thread ?
> 
> src/backend/utils/adt/genfile.c
>                 /* Ignore anything but regular files */
>                 if (!S_ISREG(attrib.st_mode))
>                         continue;

I suggested that pg_ls_tmpdir should show shared filesets like
> 169347 5492 -rw-r-----   1 postgres postgres  5619712 Dec  7 01:35
/var/lib/pgsql/12/data/base/pgsql_tmp/pgsql_tmp11025.0.sharedfileset/0.0

Should it have an extra column for the parent dir (null for nonshared filesets).
Maybe it would only show 1) files; and, 2) parents named
pgsql_tmp[0-9.]+.sharedfileset; and maybe, 3) files directly underneath (2).

Or should it require an argument to show them?  pg_ls_tmpdir(sharedfileset=False)

That allows enumerating an entire directory and its subdirs, except hidden
files, and probably except files more than one level deep.  I guess pg_ls_dir
already allows that.

Actually, my suggestion would be to make pg_ls_tmpdir expose "isdir", same as
pg_stat_file.

That's already possible using pg_ls_dir:

postgres=# SELECT name, s.size, s.modification, s.isdir FROM (SELECT 'base/pgsql_tmp'p)p, pg_ls_dir(p)name,
pg_stat_file(p||'/'||name)s;
              name              | size |      modification      | isdir 
--------------------------------+------+------------------------+-------
 pgsql_tmp11025.0.sharedfileset | 4096 | 2019-12-07 01:35:56-06 | t

pg_tmpdir() might return (name,size,modtime), or perhaps
(name,isdir,size,modtime), which would be more likely to cause deliberate
breakage if someone assumed that record[1] was the size and rest of result was
same...

Justin



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Block level parallel vacuum
Next
From: Andres Freund
Date:
Subject: Re: A varint implementation for PG?