Alvaro Herrera writes:
> Tom Lane wrote:
>> However, assuming you've gotten that detail right, then any file
>> you can't match up with a relfilenode value must be an orphan you
>> can just "rm".
> Maybe look in pg_buffercache for entries referencing those files before
> deleting. It would be su
Tom Lane wrote:
> However, assuming you've gotten that detail right, then any file
> you can't match up with a relfilenode value must be an orphan you
> can just "rm".
Maybe look in pg_buffercache for entries referencing those files before
deleting. It would be surprising to see any if no catalo
Daniel Farina writes:
> On Tue, Jan 16, 2018 at 3:04 PM Tom Lane wrote:
>> Umm ... are you accounting for catalogs that have zeroes in
>> pg_class.relfilenode? It's generally better to rely on the
>> pg_relation_filenode(oid) function than the raw column contents.
> Yeah, the catalogs are not c
On Tue, Jan 16, 2018 at 3:04 PM Tom Lane wrote:
> Daniel Farina writes:
> > I am looking at a database with a wide (~500G) divergence between the
> total
> > space expended by the database directory and the result of select
> > sum(pg_relation_size(oid)) from pg_class;.
>
> Odd.
>
> > I located
Daniel Farina writes:
> I am looking at a database with a wide (~500G) divergence between the total
> space expended by the database directory and the result of select
> sum(pg_relation_size(oid)) from pg_class;.
Odd.
> I located about 280G of apparent extra space by performing an anti-join
> be
I am looking at a database with a wide (~500G) divergence between the total
space expended by the database directory and the result of select
sum(pg_relation_size(oid)) from pg_class;.
I located about 280G of apparent extra space by performing an anti-join
between files on disk and files in the ca
