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