Re: Big 7.1 open items

At 23:27 21/06/00 -0400, Tom Lane wrote:
>"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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 |/