At 02:14 5/07/00 -0400, Tom Lane wrote:
>
>> 1. createdb
>> 2. load all blobs
>> 3. Do remaining restore steps
>
>If you're reloading everything in OID order, then blobs need no special
>ordering treatment ;-)
It's actually a bit more complex than that, in that for efficiency I put
indexes, triggers, and ACLs at the end, just after date, which once more
introduces the possibility of a conflict.
Also, the ordering is fine, but with data loading (without OID), it still
may fail (unless I put the data after the BLOBs), so a strict OID order
won't work without OID based data load. And again, that would also need to
be done in OID order, which is a big ask.
Personally, I dislike the the concept of being able to set OID on some
things but not on others. I'd prefer a lower level backup interface to
allow creation of dumped entities with specified OIDs (ie. tables, indexes
etc). That way we get a database that is indistinguishable from the
original. This might wait to see what backup techniques are possible after
WAL & slot reuse.
This is not an argument for heap_create_oid, unless it is extended to *all*
database entities, which some other people might favour. I'd be interested
in other people's thoughts on this, since I am somewhat out of my depth!
----------------------------------------------------------------
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 |/
