Re: Orphan files filling root partition after crash

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Dimitrios Apostolou <jimis(at)gmx(dot)net>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Orphan files filling root partition after crash
Date: 2024-02-28 20:16:33
Message-ID: f05f2f752535e8a9c1a1c4bee3d87f1704e69cbd.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 2024-02-28 at 20:30 +0100, Dimitrios Apostolou wrote:
> Lucky you.  It should have been "relfilenode" rather than "oid",
> > and some catalog tables don't have their files listed in the catalog,
> > because they are needed *before* the database can access tables.
>
> I actually double checked that the filenames don't appear anywhere in
> SELECT * FROM pg_class
> and that the files were multi-GB in size including all the
> 1GB-pieces. But luck was definitely a part of the equation, I didn't know
> that the files might be accessed before tables (at db startup?) or that
> "relfilenode" would be more appropriate. Why is that, where can I read
> more? I see that many (but not all) rows in pg_class have oid=relfilenode
> but for many rows relfilenode=0 which is meaningless as filename.

If you are curious about such things, start reading the source.
The object ID is immutable, and initially the filenode is the save,
but it changes whenever the table is rewritten (TRUNCATE, ALTER TABLE,
VACUUM (FULL), ...).

Yours,
Laurenz Albe

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Anthony Apollis 2024-02-28 20:22:14 Excel Source [24]] Error: System.Exception: SqlTruncateException: Numeric arithmetic causes
Previous Message Adrian Klaver 2024-02-28 19:32:51 Re: Orphan files filling root partition after crash