Re: Big 7.1 open items - Mailing list pgsql-hackers
From | Philip J. Warner |
---|---|
Subject | Re: Big 7.1 open items |
Date | |
Msg-id | 3.0.5.32.20000622163133.009b1600@mail.rhyme.com.au Whole thread Raw |
In response to | Re: Big 7.1 open items (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Big 7.1 open items
|
List | pgsql-hackers |
At 23:27 21/06/00 -0400, Tom Lane wrote: >"Hiroshi Inoue" <Inoue@tpf.co.jp> writes: >> Please add my opinion to the list. >> Unique-id filename: Hiroshi >> (Unqiue-id is irrelevant to OID/relname). > >I was trying earlier to convince myself that a single unique-ID value >would be better than OID+version for the smgr interface, because it'd >certainly be easier to pass around. I failed to convince myself though, >and the thing that bothered me was this. Suppose you are trying to >recover a corrupted database manually, and the only information you have >about which table is which is a somewhat out-of-date listing of OIDs >versus table names. This worries me a little; in the Dec/RDB world it is a very long time since database backups were done by copying the files. There is a database backup/restore utility which runs while the database is on-line and makes sure a valid snapshot is taken. Backing up storage areas (table spapces) can be done separately by the same utility, and again, it records enough information to ensure integrity. Maybe the thing to do is write a pg_backup utility, which in a first pass could, presumably, be synonymous with pg_dump? Am I missing something here? Is there a problem with backing up using 'pg_dump | gzip'? > (Maybe it's out of date because you got it from >your last backup tape.) If the files are named OID+version you're not >going to have much trouble seeing which is which, even if some of the >versions are higher than what was on the tape. Unfortunately here you hit severe RI problems, unless you use a 'proper' database backup. > But if version-updated >tables are given entirely new unique IDs, you've got no hope at all of >telling which one corresponds to what you had in the listing. Maybe >you can tell by looking through the physical file contents, but >certainly this way is more fragile from the point of view of data >recovery. In the Dec/RDB world, one has to very occasionally restore from files (this only happens if multiple prior database backups and after-image journals are corrupt). In this case, there is a utility for examining and changing storage area file information. This is probably way over the top for PostgreSQL. [Aside: FWIW, the Dec/RDB storage area files are named by DBAs to be something meaningful to the DBA (eg. EMPLOYEE_ACHIVE), and can contain one of more tables etc. The files are never renamed or moved by the database without an instruction from the DBA. The 'storage manager' manages the datafiles internally. Usually, tables are allocated in chunks of multiples of some file-based buffer size, and the file grows as needed. This allows for disk read-ahead to be useful, while storing multiple tables in one file. As stated in a previous message, tables can also be split across storage areas] Once again, I hope I have not missed a fundamental fact... ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.C.N. 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
pgsql-hackers by date: