I'm going to pick off the easy questions that Jan Mikkelsen
raised and leave the hard ones for the serious technical
types.

Ann


Jan Mikkelsen wrote:

> >>How are ACID properties maintained for page allocation
>
>Jim Starkey <jas@...> wrote:
>
> >Could you explain ACID?

Showing your age, Jim.

Jan Mikkelsen wrote:

>Presumably the relevant pointer page for
>the table would also need to be written before the page itself. I also
>would guess that the order of the writes must be PIP, pointer page, data
>page.

I believe it's PIP, data page, pointer page. The goal is to write
the page before the pointer to the page, so there's never a pointer
into the void.

>What happens if the PIP is written, but a system crash stops the pointer
>page from being written? Is the page lost to future allocations, or does
>the database startup procedure check for lost pages?

The page becomes an "orphan". The gfix utility locates orphans
and marks them as free.

>What are the recovery procedures to check database file integrity on
>startup?

As long as the header page is plausible, we'll proceed. There
is consistency checking throughout the code.

>On a slightly tangential issue: I assume that Interbase opens files with
>O_SYNC on Unix, or FILE_FLAG_WRITE_THROUGH on Win32.
>
> >I did a test about a lifetime back of the performance gain
> >by ignoring careful write altogther. The difference was in
> >the order of a couple of percentage points -- not enough to
> >get excited about.
>
>
>I assume index pages are pretty much classic b-tree indexes. Interior nodes
>ultimately pointing to leaf pages containing an ordered list of key value
>and record identifier pairs. The leaf pages are probably more complex than
>the classic structure to handle isolation and recovery.

That's about right. The upper level nodes have key values and
page numbers. Leaf nodes have key value and record number.
There is no special provision in the leaf nodes for isolation
or recovery. They are both handled by the row itself. The
index code is quite forgiving about index entries that don't
resolve to usable rows.

>The index root page presumably has pointers to the root pages of the various
>indexes on a table. How are indexes named on this page? Is it just an
>integer, or does it actually contain an index description?

The description of an index on the root page includes the
number, order, and type of keys, and the selectivity of the
index. You might ask, "What happens if the index descriptions
overflow a page?" I'll let Jim answer that one.

>Generator pages seem pretty clear (and not that interesting). Presumably a
>set of <generator_id, generator_value> pairs.

No, just generator values. The generator id is an index
into the generators.

>How are pointer pages related? Are they in a linked list, or is a list of
>pointer pages for a table stored in a special pointer page?

Pointer pages are linked and their location is stored in
the RDB$PAGES table.

>What about pages allocated to indexes? Is there a variant of a pointer page
>to see which pages are allocated to an index?

No. The index root page is in the RDB$PAGES table. The
rest of the index is linked internally.

>What I would like (and will do myself when I get the source if necessary) is
>a linkable Interbase so a single user application can run entirely in a
>single process. I'd be just as happy to link a superserver though.

The classic architecture allows (always has allowed) linking with
the application.

Ann