pg_ls_tmpdir to show shared filesets

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: pg_ls_tmpdir to show shared filesets
Date: 2019-12-13 05:39:32
Message-ID: 20191213053931.GV2082@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 12, 2019, Justin Pryzby wrote in 20191212180506(dot)GR2082(at)telsasoft(dot)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-12-13 05:45:29 Re: A varint implementation for PG?
Previous Message Masahiko Sawada 2019-12-13 05:38:03 Re: [HACKERS] Block level parallel vacuum