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