Re: [Admin] Deleting Orphan Relfilenode

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rahul Saha <rahul(dot)blooming(at)gmail(dot)com>
Cc: "pgsql-admin(at)postgresql(dot)org pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: [Admin] Deleting Orphan Relfilenode
Date: 2018-07-16 15:18:10
Message-ID: 22179.1531754290@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Rahul Saha <rahul(dot)blooming(at)gmail(dot)com> writes:
> We have a scenario where we ran Vacuum Full (2 TB Table)but due to some reason Vacuum Full failed.
> These have let almost 1 TB orphan Relfilenodes inside base directory under the concern database which does not map with pg_class.

Hm, by "fail" do you mean a database crash? Ordinary errors should have
rolled back the file creation successfully.

> For example - Select * from pg_class where relfilenode = 123456. It does not return any row but those relfilenode exist inside base.

I would not trust that query if I were you --- it will not find mapped
system catalogs. Maybe you are certain that this orphaned file wasn't
for a system catalog, but I'd still recommend using

select * from pg_class where pg_relation_filenode(oid) = 123456;

to be sure. (See also contrib/oid2name.)

> It would be great if you can suggest how to remove those orphan files. I know definitely manually deleting is not suggested so thought to know your suggestions.

If they're really orphaned, as proven by a pg_relation_filenode() check,
then manual "rm" is the thing to do. Postgres doesn't know they are
there and will not remove them.

regards, tom lane

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Ganesh Korde 2018-07-17 08:10:18 Re: Streaming replication connection break - unexpected EOF on standby connection
Previous Message Rahul Saha 2018-07-16 12:10:55 [Admin] Deleting Orphan Relfilenode