Re: Table description in the data file (Re: pg_rawdump) - Mailing list pgsql-hackers

From Stephen R. van den Berg
Subject Re: Table description in the data file (Re: pg_rawdump)
Date
Msg-id 20150204110241.GA25788@cuci.nl
Whole thread Raw
In response to Re: Table description in the data file (Re: pg_rawdump)  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
Jim Nasby wrote:
>Rather than trying to wedge this into a heap page, ISTM it'd be
>better to use a fork. Presumably if you're storing regular tuples
>that have the essential data from pg_class, pg_attribute (and maybe
>pg_type).

Well, three things:
- The information preferably is present in the same file with the pages; ideally upfront, but reachable through a
pointerwithin the file is acceptable.
 
- The information ideally is repeated at the beginning of each segment (separate file).
- The information can be in tuple form, but it is acceptable (or even preferable?) to store it as a cleartext SQL
CREATETABLE statement.  Not quite sure which one I'd prefer at this point.  The tuple version might be easier to do
machinerecovery with.  But in any case it needs needs database name, schema name, table name, column name, column type,
NULLconstraint per column.
 

The reason putting it in a separate fork is not ideal, is that
when doing recovery you might not have more than just the datafiles,
and thus it is not possible to determine which fork file
belongs to which datafile (the filenames might be lost, as well
as the directory association).
-- 
Stephen.



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: pg_basebackup may fail to send feedbacks.
Next
From: "Stephen R. van den Berg"
Date:
Subject: Re: Fetch zero result rows when executing a query?