Re: BUG #16739: Temporary files not deleting from data folder on disk

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

In response to

Responses

Browse pgsql-bugs by date

  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