Re: Lost my tablespace

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: tel medola <tel(dot)medola(at)gmail(dot)com>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: Lost my tablespace
Date: 2017-05-30 22:07:23
Message-ID: 48eeef4b-b04d-77c1-2b51-d59f23bdd203@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

On 05/30/2017 01:36 PM, tel medola wrote:
> EXACT !!!!!
>
> When I did the truncate, it erased all the files that referenced the
> table and created a new one (empty). That's why when I returned the
> physical files to the drives, it does not find the old reference and it
> is empty.
>
> I'll search how to redo the link for the correct filenode.
> Thanks very much for your help!!!
>

The thing to remember is:

https://www.postgresql.org/docs/9.3/static/storage-file-layout.html

"When a table or index exceeds 1 GB, it is divided into gigabyte-sized
segments. The first segment's file name is the same as the filenode;
subsequent segments are named filenode.1, filenode.2, etc. This
arrangement avoids problems on platforms that have file size
limitations. (Actually, 1 GB is just the default segment size. The
segment size can be adjusted using the configuration option
--with-segsize when building PostgreSQL.) In principle, free space map
and visibility map forks could require multiple segments as well, though
this is unlikely to happen in practice."

and:

"A table that has columns with potentially large entries will have an
associated TOAST table, which is used for out-of-line storage of field
values that are too large to keep in the table rows proper.
pg_class.reltoastrelid links from a table to its TOAST table, if any.
See Section 58.2 for more information."

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Adrian Klaver 2017-05-30 23:25:03 Re: Lost my tablespace
Previous Message tel medola 2017-05-30 20:36:17 Re: Lost my tablespace