| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | manojkumar(at)ameyo(dot)com |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #16739: Temporary files not deleting from data folder on disk |
| Date: | 2020-11-23 15:33:21 |
| Message-ID: | 57259.1606145601@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> There is a problem with Postgres that temporary tables being created are not
> cleaning up by Postgres itself.
Can you produce any actual evidence of that, or even better a reproduction
sequence?
> Count of temporary files-
> select count(*) from pg_ls_dir ( '/var/lib/pgsql/10/data/base/16384' ) as
> file where file::text not in (select oid::text from pg_class );
This is not evidence, because the test is completely incorrect.
* OID is not the pg_class field to use. relfilenode is closer,
although that will still mislead you for certain system catalogs.
pg_relation_filenode(oid) is really the recommended way to get the
base file name for a pg_class entry.
* Even once you've got the right filename, it's only the *base* file
name. There might be additional segments (nnn.1, nnn.2, etc) if any
table exceeds 1GB. There are likely to also be "nnn_fsm" and
"nnn_vm" subsidiary files, and maybe "nnn_init" files. All of those
would have to be excluded before concluding that files are being
leaked.
See
https://www.postgresql.org/docs/current/storage.html
for more info about what you should expect to see in a database
directory.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | J M | 2020-11-23 15:38:07 | Re: BUG #16721: ERROR: could not load library "/usr/pgsql-11/lib/rtpostgis-2.5.so": /usr/gdal32/lib/libgdal.so.28: |
| Previous Message | James Coleman | 2020-11-23 13:53:14 | Re: segfault with incremental sort |