>>> I don't understand why WAL needs to log internal operations of any of
>>> the index types.  Seems to me that you could treat indexes as black
>>> boxes that are updated as side effects of WAL log items for heap tuples:
>>> when adding a heap tuple as a result of a WAL item, you just call the
>>> usual index insert routines, and when deleting a heap tuple as a result
>>
>> On recovery backend *can't* use any usual routines:
>> system catalogs are not available.
>
>OK, good point, but that just means you can't use the catalogs to
>discover what indexes exist for a given table.  You could still create
>log entries that look like "insert indextuple X into index Y" without
>any further detail.

And how could I use such records on recovery
being unable to know what data columns represent
keys, what functions should be used for ordering?

>>> the index is corrupt and rebuild it from scratch, using Hiroshi's
>>> index-rebuild code.
>>
>> How fast is rebuilding of index for table with 10^7 records?
>
>It's not fast, of course.  But the point is that you should seldom
>have to do it.

With WAL system writes lazy and as result
probability to see "begin update" confirmation
without "done update" will be high, very high
(only log records go to disk on commit, data blocks
will be forced to disk on checkpoints - each 3-5
minutes - only).

>> I agree to consider rtree/hash/gist as experimental
>> index access methods BUT we have to have at least
>> *one* reliable index AM with short down time/
>> fast recovery.
>
>With all due respect, I wonder just how "reliable" btree WAL undo/redo
>will prove to be ... let alone the other index types.  I worry that
>this approach is putting too much emphasis on making it fast, and not
>enough on making it right.

This approach (logging all index changes) is *standard*
WAL approach and is reliable (but implementation may be
not of course -:)). This is what I've seen in books,
I didn't invent anything new and special here.
Tom, can you implement (or spend a some time for design)
hash redo/undo with "black box approach" so we could
see how good is it? I still miss are you going to use
begin/done update or "insert tuple X into index Y"
records.

Vadim


Mon, 16 Oct 2000 12:02:02 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
=?koi8-r?Q?=EF=D4=D7=C5=D4=3A_=EF=D4=D7=C5=D4=3A_WAL_and_index?=
	=?koi8-r?Q?es_=28Re=3A_=5BHACKERS=5D_WAL_status_=26_todo=29_?=
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> And how could I use such records on recovery
> being unable to know what data columns represent
> keys, what functions should be used for ordering?

Um, that's not built into the index either, is it?  OK, you win ...

I'm still nervous about how we're going to test the WAL code adequately
for the lesser-used index types.  Any ideas out there?

			regards, tom lane

Mon, 16 Oct 2000 15:19:38 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: =?koi8-r?Q?=EF=D4=D7=C5=D4=3A_=EF=D4=D7=C5=D4=3A_WAL_and_index?=
	=?koi8-r?Q?es_=28Re=3A_=5BHACKERS=5D_WAL_status_=26_todo=29_?=
> "Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> > And how could I use such records on recovery
> > being unable to know what data columns represent
> > keys, what functions should be used for ordering?
> 
> Um, that's not built into the index either, is it?  OK, you win ...
> 
> I'm still nervous about how we're going to test the WAL code adequately
> for the lesser-used index types.  Any ideas out there?

Wait for bug reports?  :-)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 16 Oct 2000 15:27:38 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: ?????: ?????: WAL and indexes (Re: [HACKERS] WAL status
	& todo)