From: Tom Lane <tgl@sss.pgh.pa.us>
To: manojkumar@ameyo.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16739: Temporary files not deleting from data folder on disk
In-reply-to: <16739-01bbd1b6e3a30313@postgresql.org>
References: <16739-01bbd1b6e3a30313@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Mon, 23 Nov 2020 08:41:07 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <57258.1606145601.1@sss.pgh.pa.us>
Date: Mon, 23 Nov 2020 10:33:21 -0500
Message-ID: <57259.1606145601@sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.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