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