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
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 |