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: | Raw Message | Whole Thread | 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 |