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

From: Manoj Kumar <manojkumar(at)ameyo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-24 15:47:38
Message-ID: CAO-7TQPk5nHpB+n5Lmv2xPRXhPLgpr47tvO0Lr_Ghk8A_dkitg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hello Tom,

Thanks for writing back.

I have checked the files, but these files are temporary and vanish once the
Postgres service is restarted.
This has been seen many times.

Adding more data to support my point in form of attachment.

*Thanks and Regards*
[image: Inline image 1]
*Manoj Kumar*
Associate Tech Lead | AMEYO
<http://www.ameyo.com/?utm_source=signature&utm_medium=email&utm_campaign=Email-Signature>
+91 9999437526
[image: Facebook] <https://www.facebook.com/AmeyoCIM> [image: Twitter]
<https://twitter.com/AmeyoCIM> [image: Google Plus]
<https://plus.google.com/+AmeyoCIM/> [image: Linkedin]
<https://www.linkedin.com/company/ameyocim>

On Mon, Nov 23, 2020 at 9:03 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

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

--

*Disclaimer:* The information in this communication is confidential and
may be legally privileged. It is intended solely for the use of the
individual or entity to whom it is addressed and others authorized to
receive it. If you are not the intended recipient you are hereby notified
that any disclosure, copying, distribution or taking action in reliance of
the contents of this information is strictly prohibited and may be
unlawful. Drishti is neither liable for the improper, incomplete
transmission of the information contained in this communication nor any
delay in its receipt. The communication is not intended to operate as an
electronic signature under any applicable law. Drishti assumes no
responsibility for any loss or damage resulting from the use of e-mails.

Attachment Content-Type Size
Postgres_10 application/octet-stream 287.1 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2020-11-24 15:51:06 Re: BUG #16743: psql doesn't show whole expression in stored column
Previous Message Tom Lane 2020-11-24 15:46:57 Re: BUG #16743: psql doesn't show whole expression in stored column